Lead story
Any Anonymous Request Can Now Own Your WordPress Site — Here's the Bug
WordPress powers roughly 43% of the web. That's a lot of surface area for a single unauthenticated remote code execution flaw — which is exactly what landed this week in the form of wp2shell, now carrying two official CVE IDs and a working proof-of-concept available to anyone who looks for it.
The vulnerability lives in WordPress core itself, not in a plugin or theme. That's the part that stings. You don't need a poorly configured third-party extension for this to bite you — a stock, freshly installed WordPress 6.9 or 7.0 site with no plugins at all is fully exploitable. An attacker sends a crafted HTTP request without any credentials and can execute arbitrary code on the server. Game over.
Since the initial disclosure, researchers have also identified a complicating factor: a persistent-object-cache condition that can affect how the vulnerability is triggered in certain hosting configurations. The practical implication is that some sites may be exploitable even where mitigations were thought to have partially applied. The full exploitation mechanism is now public, which compresses the window between "patch announced" and "actively exploited at scale" to something close to zero.
Why does this one stand out? Most critical WordPress vulnerabilities require a plugin to be installed, or at minimum an authenticated user to be tricked. wp2shell requires neither. The attack chain is short — anonymous request in, shell out — which makes it trivially automatable. WordPress botnets have historically been assembled in hours once a weaponisable bug surfaces; this is exactly the kind of flaw that feeds them.
The patch is in WordPress 7.0.1 (and backported to the 6.9 branch). If you or anyone on your team manages a WordPress site, update now. Not "schedule it for Monday." Now.
For defenders monitoring networks, watch for unusual POST requests to WordPress REST API and wp-cron.php endpoints, unexpected PHP process spawning from web server workers, and any new admin accounts or file writes you didn't authorise.
Australian context: WordPress is the dominant CMS across Australian government, media, healthcare, and small business websites. The Australian Signals Directorate's Essential Eight maturity model lists patching internet-facing services within 48 hours as a baseline control for Maturity Level 1 — this flaw is precisely the scenario that requirement was written for. Organisations running managed WordPress hosting should confirm with their providers that auto-updates are enabled or that the patch has been manually applied. ACSC advisories often lag public PoC timelines, so don't wait for an official bulletin before acting.
The broader lesson here isn't new, but it keeps needing to be said: core software vulnerabilities are categorically worse than plugin vulnerabilities because there's no opt-out. Every site on the affected version is in range, regardless of how carefully it was configured. Security-by-plugin-hygiene doesn't help you when the floor itself has a hole in it.
