wp2shell Is Already in the KEV List — Patching Won't Un-Own You

CISA put two WordPress core flaws into its Known Exploited Vulnerabilities catalogue on 21 July, alongside a DD-WRT overflow and a Langflow bug. The pair that matters here — CVE-2026-63030 and CVE-2026-60137, chained under the name wp2shell — gives an anonymous attacker remote code execution against a stock WordPress install with a single HTTP request. No login, no plugin, no theme required. By the reporting in The Hacker News, exploitation was underway within hours of the public proof-of-concept, and watchTowr's honeypots logged tens of thousands of attempts.

The mechanics, briefly: CVE-2026-63030 is a route-confusion bug in the REST API batch endpoint that skips the authentication check, and CVE-2026-60137 is a SQL injection reachable once you're inside. The SQLi is present from 6.8, the RCE from 6.9. Cloudflare's write-up adds a useful nuance — the RCE path only works when a persistent object cache is not in use. If you run Redis or Memcached as an object cache in front of WordPress, you are in a better spot on the code-execution half, though the injection is still there.

Why a mail admin should care about a CMS bug

Because so many of us run the CMS on the same iron as everything else. A company WordPress site, a Roundcube or admin panel, and Postfix/Dovecot frequently share a host — or at least a trust boundary. wp2shell's post-exploitation, as documented by Wiz, is the part that should worry you: attackers used local file inclusion to read database credentials and authentication keys, uploaded PHP webshells, and created backdoor admin accounts. One reported payload is a 150 KB shell masquerading as a security plugin, with database access, port scanning and privilege-escalation modules built in.

A webshell running as your web user on a box that also holds /var/vmail, a Dovecot config with LDAP bind passwords, or Postfix maps pointing at MySQL is a pivot, not just a defaced blog. If that host shares an OpenLDAP directory or a database instance with your mail stack, treat leaked credentials as leaked everywhere they're reused.

Patching is the floor, not the fix

Here is the point the headlines under-sell. WordPress's automatic background updates and some providers' WAF virtual patches meaningfully shrank the exposure window — Ryan Dewhurst of KEVIntel credits those defences with reducing the blast radius. But if your site was reachable and unpatched during the hours the PoC was public, updating now does nothing about a shell that's already on disk or an admin account that's already created. Wiz counted more than 100 backdoor admin accounts spun up across incidents, and at least one actor repeatedly trying to install a Go-based RAT called Overlord.

So the honest Monday-morning task isn't just "run your updates" — it's assume-breach for any instance that was internet-facing before you patched. Review the administrator user list for accounts you didn't create. Look for plugins you didn't install and recently-modified PHP files under the web root. Because the LFI grabbed database credentials and auth keys, rotate WordPress's secret keys and the database password, and rotate anything shared with your mail infrastructure. The source doesn't ship a detection command, and I won't invent one — do this against your own filesystem and user tables, by hand or with tooling you already trust.

One footnote worth sitting with: Searchlight Cyber says the chain was found using an LLM in about ten hours, and KEVIntel's Dewhurst notes AI-assisted analysis made reproducing it "trivial." The gap between disclosure and mass exploitation is closing, and your auto-update posture is now the thing standing in that gap.