WPScan vs WP Engine: What Happens When a Scanner Meets Real WordPress Hardening

What We Tested

The target: a live WordPress deployment running on WP Engine managed hosting, protected by Cloudflare CDN and Wordfence WAF. In-scope under a legitimate bug bounty programme (AS Watson / Intigriti). We ran WPScan as a SecurityClaw campaign in passive mode — the default configuration that most security scans use.

Setup:

• Tool: WPScan 3.8.28 with API token (4 requests used of the 25 daily free tier)
• Mode: Passive enumeration (default)
• API: WPScan Vulnerability Database (queried for detected component versions)

This is representative of what a standard automated WordPress security scan looks like in the real world — not against a deliberately misconfigured test server, but against a production site that's been actively hardened.

What WPScan Found (Automated Result)

WPScan passive mode returned 3 findings. All informational:

Plugins detected by WPScan: 0. Themes detected: 0. CVEs mapped: 0. WordPress version: not detected.

On paper, this looks like a scanner that failed. It didn't.

Why WPScan Was Blind — and Why That's a Good Sign

WPScan's core mechanism is fingerprinting: it identifies WordPress version, plugin versions, and theme versions from HTTP responses, then queries its vulnerability database for known CVEs against those exact versions. Without version data, it can't run CVE lookups.

WP Engine suppresses WordPress version fingerprints across all HTTP responses. This is deliberate and it's a documented security feature of managed WordPress hosting. Generator tags are stripped from HTML. ?ver= parameters on assets are removed or randomised. HTTP headers don't expose the platform version. From WPScan's perspective, it's scanning a server that reveals almost nothing about its software stack.

This is fingerprint suppression done right. It doesn't fix vulnerabilities — a vulnerable plugin is still vulnerable whether or not an attacker knows its version number. But it raises the cost of automated scanning significantly. An attacker running WPScan passive against this site gets the same result we did: 3 INFO findings and nothing to work with.

The Cloudflare CDN layer adds another obstacle. WPScan passive mode is designed for default WordPress installs where requests hit the application server directly. Against a CDN, responses may be cached, modified, or rate-limited before they reach the scanner. Some version-detection requests get throttled before they return useful data.

WPScan passive mode was defeated by the hosting environment. That is the target's security posture working.

What SecurityClaw's Manual Analysis Found Instead

WPScan returned nothing on the automated pass. SecurityClaw's AI layer ran a manual HTTP source analysis — reviewing page source, asset paths, and HTTP response patterns that automated scanning missed. The results:

WPScan: 0 components identified. Manual analysis: 7 components identified. ai_gap_fill=True.

None of the identified components have known CVEs. This target is genuinely well-maintained: WordPress 6.9 is the current release, the plugins are on recent versions, and the only potentially lagging component (Elementor Pro 3.35.1 vs 3.35.6 latest) has no security CVEs for either version.

The Honest Assessment

This is a partial result because the automated tool was defeated. But "partial" doesn't mean "the site is insecure" — the combined picture (automated + manual) actually tells a positive story about this target's security posture:

• Version suppression is configured — WP Engine and Cloudflare are blocking automated fingerprinting
• WAF is active — Wordfence adds a detection layer on top of the CDN
• All identified components are current — 0 CVEs across 7 identified components
• No misconfigured endpoints — robots.txt is clean, no sensitive paths exposed

What would change the picture: if WPScan were run in aggressive mode (--enumerate ap --plugins-detection aggressive), it would fire 20,000+ HTTP requests per plugin enumeration attempt. At that volume, Cloudflare's rate limiting would likely block it before completion — and even if it didn't, aggressive scanning without explicit written permission from the target is outside the bounds of passive bug bounty reconnaissance. It's an option, but it's not the option you default to.

The SecurityClaw lesson here: automated scanning and manual analysis are not alternatives — they're layers. WPScan told us the automated fast-path found nothing. Manual analysis told us what was actually running and confirmed it was clean. Together, that's a meaningful security assessment. Either alone is incomplete.

Understanding WPScan Modes (Most People Only Know Passive)

WPScan has three enumeration modes that significantly change what it finds:

Passive (default) — Relies on fingerprints available without aggressive probing: HTML source comments, generator tags, asset paths with version parameters, HTTP headers. Fast (~22 seconds), low noise, appropriate for initial recon. Gets defeated by any hardened managed WordPress host.

Mixed — Combines passive fingerprinting with targeted requests for specific indicators. Better coverage, higher request volume, still reasonable for authorised scans.

Aggressive — Attempts to enumerate every installed plugin and theme from a database of known paths. ~20,000 requests per enumeration run. Thorough but slow, noisy, and rate-limited on most production hosts. Should only be run in controlled environments with explicit authorisation.

Most automated scanning pipelines use passive mode because it's fast and doesn't hammer the target. This is sensible. But it means passive scanning will not detect plugins on any competently configured managed WordPress host.

The practical takeaway for WordPress site owners: if your security scanner says "no vulnerabilities found," verify it was actually running aggressive enumeration — not just passive mode that got blocked by your CDN.

WordPress Security Context

WordPress powers roughly 43% of all websites. Plugins are the dominant attack surface: the vast majority of WordPress vulnerabilities are plugin-level, not core. According to Patchstack's 2025 State of WordPress Security report, over 97% of WordPress CVEs are in plugins and themes, not in WordPress core itself.

This is why version detection matters: a site running Elementor Pro 3.24.x would have 6+ known CVEs against it (including authenticated RCE and privilege escalation). The same site on 3.35.1 has none. The delta is entirely version number. WPScan's job is to detect that version number so you can act on it.

For security professionals building WordPress assessment into their workflow: The Web Application Hacker's Handbook covers the plugin vulnerability exploitation patterns in depth — particularly authentication bypass and XSS chains that are common in WordPress plugin CVEs. Penetration Testing by Georgia Weidman covers the workflow for systematically escalating from initial enumeration to authenticated access — the same progression WPScan recon enables in a full red team engagement.

The Remediation Plan

For this specific target, no remediation is needed — the site is well-maintained and properly hardened. But the scan methodology gap is worth fixing for future campaigns:

1. Run WPScan with a clean residential IP — Cloudflare's rate limiting is partly IP-reputation based. A Kali Linux VPS IP or known security scanner IP may be throttled before a residential IP would be.
2. Use aggressive enumeration in controlled environments — For targets where aggressive scanning is authorised, run --enumerate ap,at,cb,dbe --plugins-detection aggressive with the API token to maximise coverage.
3. Supplement with authenticated scanning — WPScan can authenticate with WordPress credentials (--username admin --password [pass]) and enumerate plugins visible only to authenticated users. This is the difference between black-box and grey-box WordPress assessment.

Assess Your WordPress Deployment

If you're running WordPress, start here:

SecurityClaw's WordPress scanning layer handles mode selection automatically based on what the initial passive scan returns — escalating to targeted enumeration when passive mode is defeated without triggering blanket aggressive scanning on every campaign.

Learn about SecurityClaw →

SecurityClaw is in active development. The demos section documents real campaign results as the platform matures.