16 vulnerabilities, zero scanners
Every automated scanner bounced off Cloudflare. So we stopped scanning and started asking. The WordPress REST API told us everything — usernames, plugin stack, media library, infrastructure IDs. Here's how AI-assisted manual enumeration found what traditional tools couldn't.
The setup
Authorized security assessment of a client's newly launched product marketing site. WordPress on GoDaddy Managed WordPress, fronted by Cloudflare. Single-page site with a contact form. About as small an attack surface as it gets.
We started where every assessment starts — automated scanning.
$ nmap -sV -Pn [REDACTED] # port scan + service detection $ wpscan --url [REDACTED] # WordPress scanner $ nikto -h [REDACTED] # web server scanner $ gobuster dir -u [REDACTED] # directory enumeration
Nmap returned results. Everything else failed. WPScan got a 400 BAD REQUEST. Nikto timed out. Gobuster ate 403s. Cloudflare was doing exactly what it was paid to do — kill automated scanning.
So we stopped scanning and started thinking.
What Cloudflare doesn't block
Cloudflare protects against scanners. It does not protect against legitimate HTTP requests to endpoints the application intentionally exposes. WordPress ships with a REST API that's designed to be publicly accessible. It responds to normal GET requests. Cloudflare has no reason to block them.
One request told us everything:
GET /wp-json/wp/v2/users HTTP/1.1
Host: [REDACTED]
[{"id":1,"name":"98[REDACTED]","slug":"98[REDACTED]",
"avatar_urls":{"96":"https://secure.gravatar.com/avatar/18bb..."},
"link":"https://[REDACTED]/author/98[REDACTED]/"},
{"id":2,"name":"Ja[REDACTED]","slug":"ja[REDACTED]",
"avatar_urls":{"96":"https://secure.gravatar.com/avatar/48c6..."}}]
Two user accounts. Full usernames. Gravatar email hashes. Author archive URLs. No authentication required. One curl command.
The takeaway: WAFs protect against scanners, not against people who know what to ask for.
The findings
Sixteen total. Two critical, three high, seven medium, four informational. Here are the ones that matter.
/wp-json/wp/v2/users returned the complete user list to unauthenticated requests. User ID 1 was a hosting-generated admin account — the numeric prefix pattern confirmed automated provisioning. User ID 2 was the Elementor page builder user with editor onboarding flags still visible in the response.
A separate enumeration vector existed at /?author=1, which rendered a full author archive page with the admin username in the page title. Even locking down the REST API would still leak usernames through author archives.
Impact: Username harvesting for targeted brute-force, credential stuffing, and social engineering. The admin account was auto-provisioned — if the password was never changed from the hosting setup email, it's game over.
Nmap found ports 2083 (cPanel), 2087 (WHM), and 2096 (Webmail) open and serving nginx. WHM on 2087 provides full server control. These were the only ports nmap found that Cloudflare wasn't proxying — the management plane was accessible from any IP on the internet.
Impact: Combined with known usernames from C-1, an attacker has a direct brute-force path to the hosting control panel.
The WordPress login page exposed the GoDaddy Managed WordPress site UUID, a full SSO URL, and a ?wpaas-standard-login=1 parameter that bypasses GoDaddy's SSO entirely to present the raw WordPress login form. Combined with C-1 usernames — direct path to brute-force.
/wp-json/wp/v2/media returned every uploaded file with complete metadata: original filenames, upload dates, all generated thumbnail sizes, file paths, author attribution, and WP Smush image optimization statistics revealing plugin configuration. The entire upload directory structure was mapped in a single request.
The site's only interactive endpoint used reCAPTCHA v2 checkbox, which is routinely bypassed by CAPTCHA-solving services at roughly $3 per thousand solves. The site key was exposed in the page source.
The REST API kept talking
Once we had the users endpoint open, we checked what else the API would give up without authentication.
/wp-json/wp/v2/types revealed every registered custom post type, which maps directly to installed plugins. Elementor Pro, CoBlocks, Astra Pro with Site Builder, WP Smush, DesignSetGo — all fingerprinted through their custom post types without probing a single plugin readme or guessing paths.
The homepage had 781 revisions linked in the API response. The revision content was auth-gated (good), but the count was exposed. In nearly 800 revisions of a marketing page, the odds of finding draft content, internal notes, or removed pricing are non-trivial.
The RSS feed at /feed/ confirmed the WordPress version — 6.9.4 — in its generator tag, along with the admin username attributed as the author of a default GoDaddy sample blog post that was still published.
Elementor custom code snippet and floating button endpoints both responded to unauthenticated requests. Currently empty, but if anyone adds custom code snippets later, they'll be publicly readable.
Version context
WordPress 6.9.4 (released March 11, 2026) patched three CVEs that were incompletely fixed in a chaotic triple-release cycle:
| CVE | Issue | Impact |
|---|---|---|
| CVE-2026-3907 | PclZip path traversal | Malicious ZIP → file writes outside intended directories |
| CVE-2026-3906 | Notes authorization bypass | Lower-privileged users access higher-role content |
| CVE-2026-3908 | getID3 XXE injection | Author+ → arbitrary file reads including wp-config.php |
All require authentication. The site was on 6.9.4, so the core was patched. But the chain is worth understanding: combine user enumeration (C-1) with a compromised subscriber account and the XXE vector, and you're reading database credentials.
What the scanners missed
| Tool | Result |
|---|---|
| WPScan | Blocked — 400 BAD REQUEST |
| Nikto | Timed out |
| Dirb | Blocked — 400 BAD REQUEST |
| Gobuster | Blocked — 400 BAD REQUEST |
| Manual REST API enumeration | 16 findings |
Cloudflare also blocked xmlrpc.php — but that was the WAF, not a WordPress-level disable. If Cloudflare is ever bypassed via direct IP access, XML-RPC would be live for brute-force amplification.
What worked
Not everything was broken. The site had some solid security posture worth noting:
WordPress core was current at 6.9.4. Page revision content was auth-gated. Plugin and theme list endpoints required authentication. The Elementor template library required auth. The default readme.html was removed. The contact form had CAPTCHA (weak variant, but present). GoDaddy managed hosting handles OS-level patching automatically.
The problem wasn't negligence — it was the gap between "protected by Cloudflare" and "actually hardened." The WAF created a false sense of security while the API happily answered every question it was asked.
What the AI changed
This assessment didn't find anything a skilled human pentester couldn't find manually. The difference is speed and context.
When nmap returned results, the skills engine recommended API security testing workflows relevant to the WordPress REST API context. When we identified plugins via custom post types, searchsploit queried for known CVEs against those specific plugins in the same workflow. When the version was confirmed via RSS, the skills engine pulled the exact CVE context for 6.9.4 including the chaotic triple-release history.
The entire chain — reconnaissance, enumeration, analysis, version research, exploit correlation, and report generation — happened in a single session. No context switching between terminals, browsers, and CVE databases.
Traditional automated scanning found zero findings on this target. AI-assisted manual enumeration found sixteen.
Assessment disclosure: This assessment was conducted with written authorization against the client's own infrastructure. No exploitation was attempted. All findings are from publicly accessible, unauthenticated endpoints. Identifying details have been redacted.
When the scanners fail, you need methodology
Kali MCP integrates 18+ offensive security tools and 753 guided skill workflows into an AI-assisted pentesting platform through Claude Desktop. It doesn't just run tools — it recommends the right approach when automated scanning hits a wall.
Learn more