Security & Monitoring

WP Warden checks every plugin, theme, and WordPress core version across all your sites against known CVE databases. Scans run automatically on a schedule, but you can also trigger one on demand.

1. Automatic scans happen daily

   
   WP Warden runs a full fleet vulnerability scan every day at 4:00 AM using WPVulnerability.net. If Patchstack is configured instead, that daily scan is replaced by a scheduled Patchstack sync every 6 hours with virtual-patch status.
2. To run a manual scan

   
   Go to Vulnerabilities in the sidebar. Click Run Global Security Audit at the top of the page. WP Warden immediately scans all connected sites and refreshes the results.
3. Review the vulnerability list

   
   Results show: affected plugin/theme name, CVE ID (if available), CVSS severity score (0–10), severity badge (Critical / High / Medium / Low), affected version range, and the fixed-in version.
4. Check for virtual patches (Patchstack users)

   
   Vulnerabilities with an active Patchstack virtual patch show a Warning severity instead of Critical/High, and display the note: “Virtual patch active via Patchstack. Update still recommended.”
5. Remediate vulnerabilities

   
   For each vulnerability, go to the Plugin Inventory and update or deactivate the affected plugin. See How to update a plugin.

Screenshot: Vulnerabilities page

The vulnerability feed showing severity badges, CVE IDs, affected plugins, and the fixed-in version column.

WP Warden generates alerts automatically for downtime, cron failures, broken links, vulnerabilities, and more. Here’s how to view, filter, resolve, and snooze them.

1. View all alerts

   
   Click Alerts in the sidebar. The alerts page lists all active alerts across your entire fleet.
2. Filter by severity or type

   
   Use the filter dropdowns to narrow by: Severity (Critical / High / Warning / Info) or Type (downtime, cron_failure, vulnerability, zombie_plugin, broken_link, visual_regression, etc.). As a rough triage order: Critical (e.g. the site is unreachable, or a vulnerability with a high CVSS score) needs action now. High/Warning (lower-severity vulnerabilities, a broken link, a stale cron) can usually be scheduled rather than dropped everything for. Info is for awareness only. When several alerts are open at once, work down from Critical.
3. Resolve an alert

   
   Click the Resolve button on an alert row. For certain alert types (cron failures, broken links, zombie plugins, vulnerabilities), WP Warden performs a verify-before-resolve check. If the underlying issue is still present, a “Still Persisting” modal explains why. You can choose to Force Resolve to override.
4. Snooze an alert

   
   Click the clock icon to snooze an alert until a future date/time. Snoozed alerts are suppressed from notifications and the dashboard badge until the snooze period expires.
5. Configure which alerts trigger emails

   
   Go to Settings → Notifications tab to control which alert types send email notifications. See notification preferences.

Screenshot: Alerts page with severity filter and Resolve button

The alerts list with severity color-coding (red border = critical, amber = warning, blue = info), filter dropdowns, and per-row Resolve and Snooze buttons.

WP Warden checks DNS records, SSL certificates, email authentication (SPF, DKIM, DMARC), and global DNS propagation for all your sites every 6 hours and alerts you when something changes.

1. Go to DNS Health

   
   Click DNS Health in the sidebar to see the fleet-wide DNS overview.
2. Review the DNS health scores

   
   Each site has a 0–100 DNS Health Score based on five categories: Email Auth (SPF/DKIM/DMARC), SSL Security, DNS Records (A, MX, Nameservers), Uptime, and Propagation across 6 global resolvers.
3. Click a site to see full details

   
   The per-site DNS detail page shows every individual check result — pass, fail, or warning — with timestamps.
4. Read fix guides for failed checks

   
   For each failed check, a Fix Guide button appears. Click it for step-by-step remediation instructions including exact DNS record values to copy into your DNS provider.
5. Trigger a manual recheck

   
   Click Recheck Now on any site’s DNS detail page to run an immediate check without waiting for the 6-hour scheduled run. Rate-limited to once per 10 minutes.

Screenshot: DNS Health fleet overview

The fleet table showing each site’s DNS score, category breakdown bars, and last check time.

Screenshot: Per-site DNS detail page

Individual check results for A record, MX, SPF, DKIM, DMARC, SSL certificate expiry, and propagation across 6 resolvers.

WP Warden probes every site every 5 minutes from the backend server, completely independent of the WordPress plugin. When a site goes down you get an alert instantly — not on the next heartbeat.

1. Uptime monitoring is automatic

   
   No setup required. Every site you add to WP Warden is automatically included in the 5-minute uptime probe cycle.
2. View uptime statistics

   
   Open any site’s detail page and scroll to the 30-Day Health Trend chart, which overlays response time as an amber dashed line alongside the health and security score trends. Hover any point for the exact response time at that check.
3. View downtime incidents

   
   When a site was down, downtime incidents are recorded with: start time, end time, duration, and root cause (DNS failure, timeout, connection refused, HTTP 5xx). These appear in the Uptime section of client reports.
4. Check the active alert when a site is down

   
   Go to Alerts. A Site Unreachable critical alert is created automatically the moment a probe fails. The alert is automatically resolved when the site comes back up — no manual action needed.

Screenshot: Site detail page — 30-Day Health Trend chart

The interactive sparkline chart showing health score (green), security score (blue), and response time (amber dashed) over 30 days.

Every time WP Warden applies a plugin, theme, or core update, it automatically captures before/after screenshots and compares them pixel by pixel. If the site looks different, you get a Visual Regression alert.

1. Visual regression runs automatically after updates

   
   No configuration needed. Whenever an update command is executed via WP Warden (toggle, bulk update, or maintenance window), a before-screenshot is captured, then a second after-screenshot is taken, and the two are diff’d.
2. Check for Visual Regression alerts

   
   If the pixel mismatch exceeds the threshold (default 5%), a Visual Regression warning alert appears in the Alerts page. Click it for details.
3. View the before/after images

   
   Open a site’s detail page and go to the Regressions tab. Each entry shows the diff score (%), and you can click to view the before screenshot, after screenshot, and the red-highlighted diff image side by side.
4. Investigate the change

   
   A high diff score means something visible changed on the homepage. This could be a legitimate UI update or an unintended breakage. Open the site in a browser to confirm.
5. Resolve the alert

   
   Once you have confirmed the change is expected (or fixed the issue), return to Alerts and click Resolve on the visual regression alert.

Screenshot: Visual Regression — before/after/diff view

Three screenshots side by side: before the update, after the update, and the pixelmatch diff image with red-highlighted changed areas.

WP Warden hashes every core, plugin, and theme file and diffs it against a known-good baseline, and separately scans for malicious code patterns and blocks brute-force logins — so a compromise gets caught whether it shows up as an unexpected file change or as a webshell that was never a “change” at all.

1. Hash-based change detection (core, plugins, themes)

   
   Every file in scope is SHA-256 hashed on each scan and compared to the last known-good baseline. Core files are additionally cross-checked against the official WordPress.org checksum manifest, so tampering is caught even on the very first scan.
2. Malware & webshell signature scanning

   
   Independent of hash diffing, WP Warden scans file content for known malicious-code patterns — obfuscated eval()/base64_decode() chains, dynamic function construction, and webshell request patterns. This catches a webshell even if it was already present before monitoring started, which a hash baseline alone cannot.
3. Uploads directory coverage

   
   wp-content/uploads is excluded from hash-diff baselining (it changes constantly by design) but is still scanned for disallowed executable extensions and malicious content — the single most common place a dropped webshell hides.
4. Uploads directory hardening

   
   The WP Warden plugin pushes a server rule into wp-content/uploads denying execution of PHP and other script extensions, so even a file that slips past scanning can’t be run directly.
5. Brute-force login protection

   
   Repeated failed logins from the same IP are rate-limited and locked out automatically. If the same IP targets multiple sites in your fleet within an hour, WP Warden raises one fleet-wide alert instead of one alert per site.
6. Configure scan scope and review flagged files

   
   Open a site’s File Integrity page to set scan scope (core only, core + plugins, core + themes, or all) and frequency (daily or hourly), and review every modified, added, deleted, or content-flagged file with its matched pattern.
7. Execution hardening for other directories & plugins

   
   The same verified deny-execution technique used for uploads extends to wp-content/cache, wp-content/upgrade, and direct access to wp-includes — enable each from the same File Integrity page. Individual plugins can also be hardened as an opt-in: WP Warden runs a pre-flight risk scan first, then a trial period that automatically reverts if you don’t explicitly confirm it or if the site’s health score drops.

Execution Hardening stops a planted file — a dropped webshell, a backdoor an attacker uploaded — from ever running as PHP, even if it makes it onto your server. It does this by denying direct execution in a directory or plugin folder, then immediately verifying the rule actually works with a live test request, rather than just assuming a written rule took effect.

1. Deny-execution, not file locking

   
   WP Warden adds a server rule (.htaccess) denying direct execution of code-like files in the target location. This is deliberately not permission-based (chmod) locking: a same-owner attacker process can chmod its own file back, and WordPress’s own plugin/theme updater deletes and recreates whole directories on update regardless of any per-file permission. Denying execution sidesteps both problems — it doesn’t matter whether a file gets modified or a new one gets dropped, because nothing in that location can ever run as PHP in the first place.
2. Live-verified, never just assumed

   
   Some hosts (Nginx, or Apache with .htaccess support disabled) silently ignore these rules. After applying, WP Warden drops a probe file and makes a real HTTP request to it — the status you see always reflects what an actual request would experience, never just “the rule file exists.”
3. Four curated directories, low risk

   
   wp-content/uploads, wp-content/cache, wp-content/upgrade, and wp-includes — none of these legitimately need to serve a PHP file directly, so toggling hardening on for any of them from a site’s File Integrity page has essentially no downside.
4. Plugin hardening is opt-in and higher-risk

   
   Some plugins genuinely need a directly-hittable file — a payment gateway callback, a license check, a webhook receiver. Hardening a plugin that relies on one of those will break that specific feature, which is why plugin-level hardening always goes through Scan → Apply → Confirm rather than applying blind.
5. Scan for risk before applying

   
   A heads-up scan (not an exhaustive audit) flags files whose name suggests they expect a direct hit — matching patterns like callback, webhook, ipn, license, or gateway. Review every flagged file before continuing.
6. Trial period with automatic rollback

   
   Applying a plugin hardening starts a 48-hour trial. If your site goes down, or its health score drops meaningfully, during that window, WP Warden automatically reverts it as a precaution — you don’t have to notice and fix it yourself. An unconfirmed trial always auto-reverts once it expires; hardening never silently becomes permanent on its own. You can also revert manually at any time, for any reason.
7. Requires the site to be online

   
   Every hardening action needs your site reachable to actually take effect and be verified. If WP Warden can’t reach your site when you trigger an action, it tells you immediately instead of queuing something that could never complete. If a site goes offline while a plugin hardening is mid-trial, that trial is automatically reverted as a safety precaution once WP Warden notices.

When the file-integrity scanner flags a file, you can optionally connect your own AI provider — Claude, ChatGPT, Gemini, or a locally-hosted model — for an independent second opinion before deciding what to do about it.

1. Connect your AI provider

   
   Go to Settings → AI Security. Toggle it on, choose a provider (Claude, ChatGPT, Gemini, or Local / OpenAI-compatible for something like LM Studio or Ollama), and enter your API key — or, for a local server, its URL (e.g. http://localhost:1234/v1). No API key is needed for a local server.
2. Don’t have a key yet?

   
   Create one in your own account on the provider’s own site — WP Warden doesn’t issue these: Anthropic (Claude) — “Get your API key” · OpenAI (ChatGPT) — API keys · Google AI Studio (Gemini) — API keys. WP Warden only ever sees the key you paste in, never your provider account credentials.
3. Choose which locations the AI can see

   
   Turn Core, Themes, Plugins, mu-plugins, and Uploads on or off independently. Only files inside an enabled zone are ever sent for a second opinion — nothing is scanned proactively, only files the deterministic scanner already flagged.
4. Set a daily call limit

   
   Cap how many findings per day get sent to your AI, so your own usage costs with that provider stay predictable.
5. Test the connection

   
   Click Test Connection to confirm WP Warden can reach your provider (or local server) and get a real response back before relying on it.
6. Review AI verdicts on flagged files

   
   Open a site’s File Integrity page. A finding that has completed AI review shows a colored 🤖 badge — malicious, benign, or uncertain — with the AI’s rationale on hover.
7. Quarantine or permanently delete a confirmed threat

   
   Click Quarantine on site to rename and lock the file in place on the live site — reversible, evidence preserved. Once quarantined, a separate Permanently delete button appears as a deliberate second step.
8. Track your usage

   
   Settings → AI Security shows token usage for today, this month, and all time, so you can see roughly what you’re spending with your own provider.