A WordPress Bug Lets Strangers Run Code on Your Site. No Login Required.

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.
• Researcher Adam Kues of Assetnote, the attack surface team at Searchlight Cyber, 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, meaning an attacker who has never touched your site can make its server run commands of their choosing. It is roughly the worst thing that can happen to a web application, and it is 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, the attack surface management arm of Searchlight Cyber. 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" is not an option when the risky code is the platform.

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 upgraded to the current line in the past few months was exposed.

WordPress is not relying on admins to notice. It has switched on what it calls forced updates through the auto-update system, which means the fix is being pushed out to sites whether or not the owner logs in this weekend. For most small sites that is the right call. For managed hosts and agencies it means checking that auto-updates were not disabled somewhere along the way.

What should site owners actually do?

Open your admin dashboard and confirm you are on 6.9.5 or 7.0.2. If you are 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 are on.

Then assume, for a moment, that something got in before Friday. Look at your list of admin users. Check for accounts you do not recognise. Look at recently modified files in your WordPress folder, especially anything ending in .php that you did not put there. If your site handles customer data or payments, treat this as a possible incident and pull your server logs while they are still fresh.

What about ordinary visitors?

If you read a small business's blog or buy from a WordPress shop, there is nothing special you need to do. Watch for the usual signs a site you use has been tampered with: unexpected password reset emails, odd redirects to unfamiliar pages, or checkout screens that suddenly look different. Report anything strange to the site owner rather than typing your card details into it.

The bigger lesson, again, is boring and true. Auto-updates exist because humans forget. Friday's bug is the kind that turns "I'll patch it Monday" into a very long weekend.