A WordPress Bug Lets Strangers Run Code on Your Site. No Login Required.
Every WordPress 6.9 and 7.0 site was exposed until a Friday emergency patch. The fix is being force-installed.
Key points
- WordPress shipped emergency releases 6.9.5 and 7.0.2 on Friday to fix a flaw that lets anyone on the internet run code on a vulnerable site.
- The bug sits in WordPress core, so a fresh install with no plugins is still exploitable.
- Every site running WordPress 6.9 or 7.0 was at risk before the patch.
- Adam Kues of Assetnote, Searchlight Cyber's attack surface management arm, found and reported the flaw.
- WordPress is pushing the fix through forced auto-updates rather than waiting for admins to click.
WordPress has a bad one.
On Friday the project shipped two emergency releases, 6.9.5 and 7.0.2, to close a flaw that lets a complete stranger take over a site by sending a single web request. No password, no account, no tricking a logged-in admin. Just a request.
That class of bug has a name in security circles: unauthenticated remote code execution, where an attacker who has never touched your site can make its server run commands of their choosing. It's roughly the worst thing that can happen to a web application, and it's the same primitive that fuelled the great PHP-era mass defacements of the 2010s.
The flaw, which researchers are calling wp2shell, was found by Adam Kues at Assetnote, Searchlight Cyber's attack surface management arm. It was first reported by The Hacker News.
How bad is this, really?
Bad, because the bug is in WordPress itself, not in a plugin. A brand-new WordPress install with zero add-ons and a default theme was exploitable. That matters because WordPress runs a large share of the public web, and "just remove the risky plugin" isn't an option when the risky code is the platform itself.
Every site on WordPress 6.9 or 7.0 was in range until the Friday patch landed. Older long-term-support branches sit outside that window, but anyone who'd upgraded to the current line in the past few months was exposed. We covered a separate WordPress zero-day found by an AI-assisted tool just days earlier, on 15 July, in Intruder's AI 'vulnerability vending machine' finds a WordPress zero-day on its own. Two WordPress core-level scares in a week is not a pattern to ignore.
WordPress isn't relying on admins to notice. It's switched on forced updates through its auto-update system, pushing the fix to sites whether or not the owner logs in this weekend. For small sites that's the right call. Managed hosts and agencies should confirm auto-updates weren't disabled somewhere along the way.
What should site owners actually do?
Open your admin dashboard and confirm you're on 6.9.5 or 7.0.2. Still on 6.9.4 or 7.0.1? Update by hand right now. If your host manages updates for you, ask them in writing which version you're on.
Then assume, for a moment, that something got in before Friday. Check your admin user list for accounts you don't recognise. Look at recently modified files in your WordPress folder, especially any .php files you didn't put there. If your site handles customer data or payments, treat this as a possible incident and pull your server logs while they're still fresh.
Should you worry if you're just a visitor?
If you read a small business's blog or buy from a WordPress shop, there's nothing special you need to do. Watch for the usual signs a site has been tampered with: unexpected password reset emails, odd redirects, or a checkout screen that suddenly looks different. Report anything strange to the site owner rather than typing your card details into it.
The boring truth is that auto-updates exist because humans forget. Friday's bug is exactly the kind that turns "I'll patch it Monday" into a very long weekend.
