Unauthenticated RCE in WordPress Core: Update to 6.9.5 / 7.0.2 Immediately

What Happened

A critical unauthenticated remote code execution vulnerability — tracked as wp2shell — was disclosed in WordPress core this week, affecting every site running WordPress 6.9 or 7.0. According to The Hacker News, an anonymous HTTP request with no authentication, no valid session, and no plugin involvement is sufficient to execute arbitrary code on a vulnerable installation.

WordPress shipped fixes on Friday: 6.9.5 and 7.0.2. The project simultaneously enabled what it calls "forced updates" through its auto-update mechanism, pushing the patch to sites that have automatic background updates enabled.

Why It Matters

Most WordPress vulnerability disclosures target plugins or themes — the ecosystem is enormous and plugin quality varies wildly. A flaw in core is categorically worse: there is no "unaffected configuration" short of being on a patched version. A bare WordPress install with zero plugins, default theme, and no customization was fully exploitable until Friday.

Unauthenticated RCE is the worst class of web vulnerability. An attacker needs no foothold — no compromised credential, no brute-forced account, no social engineering. A single crafted HTTP request is enough to drop a webshell, exfiltrate the database, pivot to the underlying host, or enlist the server in a botnet. Exploitation at scale is trivial: automated scanners can fingerprint WordPress version headers and fire the payload in bulk across millions of sites.

The window between disclosure and mass exploitation for this class of bug is measured in hours, not days. If your site was reachable and unpatched at any point between the vulnerability becoming known and the forced-update push landing, treat it as potentially compromised.

What to Do

1. Verify your version right now. Log in to wp-admin → Dashboard → Updates, or check wp-cli core version if you have CLI access. You need to be on 6.9.5 (if on the 6.x branch) or 7.0.2 (if on 7.x). If you are not, update manually — do not wait for the auto-update to cycle.

2. Confirm the forced auto-update landed. WordPress logs auto-updates to the database and optionally emails the admin address. Check wp-admin → Dashboard → Updates for the "This site is automatically kept up to date" message and the version shown.

3. Audit access logs for exploitation attempts. Filter your Nginx/Apache access logs for the request pattern associated with wp2shell payloads. Indicators of compromise include unexpected POST requests to wp-cron.php, xmlrpc.php, or wp-admin/admin-ajax.php from IPs that have no prior session, especially around the disclosure window. Look for file creation in wp-content/uploads or wp-content/themes.

4. If you suspect compromise, don't just patch. Patching closes the door but does not evict an attacker who already entered. Scan for unfamiliar PHP files (find wp-content -name '*.php' -newer wp-config.php), review recently modified core files against a clean WordPress download, rotate database credentials, and check for new admin accounts.

5. Harden auto-updates going forward. If you have disabled WordPress core auto-updates (AUTOMATIC_UPDATER_DISABLED or WP_AUTO_UPDATE_CORE = false in wp-config.php) for stability reasons, build a process to apply core security releases within 24 hours of publication. Forced updates exist precisely for situations like this.