wp2shell, looking back: the July break-in route through WordPress itself

Written in October 2026, three months after the event, in the week of php2shell. The two stories have a lot in common.

What happened

On 17 July 2026, the security company Searchlight Cyber published a way to take over a WordPress site without logging in. It came to be called wp2shell. It joined two flaws in WordPress itself, not in a plugin:

• CVE-2026-63030, in the part of WordPress that lets other software send it several requests at once. A request sent that way could skip the check on who was asking.
• CVE-2026-60137, a database flaw that normally needs a logged-in user. Through the first flaw, it didn't.

Together they let a stranger run their own code on the server. The route was found, according to Wiz, with the help of an AI model.

WordPress released the fix the same day: 7.0.2, with 6.9.5 and 6.8.6 for older branches. WordPress 6.9 and 7.0 sites were open to the full takeover. Sites on 6.8 needed a smaller fix, and versions before 6.8 weren't affected.

How fast it moved

17 July	Published and fixed. Wordfence saw the first probing that day, and a first attack attempt thirteen minutes after it.
Within hours	Ready-made attack tools appeared on GitHub, and dozens followed.
20 July	Wiz reported several groups breaking into sites and leaving ways back in.
21 July	The US government added both flaws to its list of flaws known to be attacked (CISA's KEV).

What the attackers left behind

Wiz described what it found on sites that were broken into:

• Plugins nobody installed. One posed as a security scanning tool called "CMSmap" and carried a full control panel for the attacker. Another added a hidden address that ran any command sent to it.
• A one-line back door that answered "page not found" to everyone except the attacker.
• Attempts to read wp-config.php, the file that holds the database password and the site's secret keys.

The important point for site owners: updating WordPress removed the hole but not the intruder. A site broken into on 17 July and updated on 18 July still had the attacker's plugin installed.

What went right

WordPress turned on forced automatic updates for affected sites, and on most sites the fix installed itself. Wiz measured the effect: when the flaws were published, a quarter of the organisations it watches had a vulnerable WordPress site open to the internet. A day later it was a tenth.

That is WordPress at its best, and it is worth saying so. It also shows who was left behind: sites with automatic updates switched off, sites on a host that holds updates back, and sites nobody had looked at in years.

What to check now

If you run WordPress 6.8 or later, three months on:

1. Check the version. It should be 7.0.2, 6.9.5 or 6.8.6, or later.
2. Go through the plugins list for anything you don't recognise, including anything called CMSmap. Then check the users list for administrators you didn't add.
3. If anything looks wrong, treat the site as broken into. Restore from a backup taken before 17 July, change every password, and change the secret keys in wp-config.php and the database password.

What it tells us

July was a flaw in WordPress. October was a flaw in PHP, underneath it. Both were found with AI help, and both were being attacked within hours of being published. Three months apart.

A WordPress site is software that has to be watched for ever, and the watching is getting harder. A site moved to plain files has no WordPress to break into and no plugins to hide in. That is what Offramp does, and the site still looks exactly as it does today.