If your store runs WordPress, it almost certainly patched itself two weeks ago. That is the good news, and it is also the trap. The wp2shell exploit chain was public and under attack before most site owners heard the name, and a forced update does not undo a compromise that already happened. Patched and clean are two different states. Right now you only know one of them.
Here is what happened, and the short list of checks that tell you which state your site is in.
What wp2shell actually is
On July 17, 2026, WordPress released versions 6.8.6, 6.9.5 and 7.0.2 to fix two flaws. Alone, neither is a disaster. Chained, they hand over the whole site.
CVE-2026-60137 is a SQL injection in the author__not_in parameter of WP_Query. On its own it needs an authenticated user. CVE-2026-63030 is a route confusion bug in the REST API batch endpoint, and according to VulnCheck’s analysis of the patch commits, it bypasses the check that limited the SQL injection to logged-in users. Put them together and an anonymous request to a stock install becomes a rogue administrator account and a webshell.
No plugin required. No theme required. No password required. That is what makes this one different from the usual WordPress security story, where the hole is in some abandoned plugin you can just delete.
The discovery detail is worth a pause. Searchlight Cyber researcher Adam Kues found the chain using OpenAI’s GPT-5.6 Sol, and wrote that the bugs and a working exploit came together in roughly ten hours. In his own words, quoted by Dark Reading: “no security researcher could have found and completed this exploit chain in 10 hours without AI.”
How fast it moved
VulnCheck verified more than two dozen unique public proof-of-concept exploits by Sunday, July 19, two days after disclosure. Its Canary Intelligence network observed exploitation against production systems by July 20.
Wiz Research, which published its own exploitation report on July 20, reported that 60% of organizations it monitors running WordPress had at least one vulnerable instance when the CVEs were published, and 25% had a vulnerable server exposed to the internet. Within 24 hours those figures fell to 50% and 10% as patching kicked in.
Wiz also documented what attackers did after they got in: malicious plugin uploads through update.php?action=upload-plugin, user enumeration through the REST users endpoint, and local file inclusion attempts aimed at wp-config to steal database credentials. One payload was a 150KB webshell disguised as a plugin named after a legitimate security tool, complete with a graphical file manager, database access and privilege escalation modules.
Jake Knott, principal security researcher at watchTowr, told Dark Reading the company’s honeypot network recorded tens of thousands of exploitation attempts and more than 100 backdoor accounts created by different threat actors. His advice was blunt: inspect your WordPress instances for new administrator accounts and unfamiliar plugins regardless of whether you patched.
What to do: stop treating “auto-update is on” as an answer. Open your dashboard and read the actual version number. You want 6.8.6, 6.9.5 or 7.0.2 at minimum. Anything in the 6.9.0 to 6.9.4 or 7.0.0 to 7.0.1 range is still exposed to the full chain.
Why patching does not close the case
WordPress.org enabled forced updates for affected versions, which by any reasonable estimate saved an enormous number of sites. But as the incident response team at Eye Security noted in its defenders guide, forced updates do not reliably reach sites that disabled auto-updates, and a site compromised before the patch arrived stays compromised afterwards.
There is a nastier wrinkle. Eye Security’s analysis found the decisive steps of the attack ride inside REST batch POST bodies that rarely show up in web server access logs. A clean run can leave almost nothing in /var/log/nginx/ or /var/log/apache2/. Quiet logs are not evidence of safety here. The database is the primary evidence, not the log files.
The checks that actually tell you something
Start with users. Go to Users, filter by Administrator, and read every row. The public exploit code creates accounts with recognisable fingerprints: logins prefixed wp2_ or w2s_, and email addresses on the domains @wp2shell.invalid or @wp2shell.shellcode.lol, per Eye Security’s indicator list. Match on the prefix, not the exact string, because the suffixes are random.
Then check plugins. Look at wp-content/plugins/ over FTP or your host’s file manager and compare the folder list against what your Plugins screen shows. A directory you do not recognise, especially one created after July 16, deserves attention. Wiz observed attackers registering custom REST routes with a permissive callback to run base64-encoded shell commands, all wrapped in something that looks like an ordinary plugin.
Then check file timestamps. On a Linux host, Eye Security suggests a first pass of find DOCROOT -name "*.php" -newermt "2026-07-16" to surface PHP files created or modified inside the exposure window.
Searchlight Cyber maintains a live checker at wp2shell.com, and Eye Security published a free Compromise Scanner plugin in the WordPress.org directory that looks for the database artifacts the chain leaves behind. Both teams are clear about the limit: a clean scan lowers your risk, it does not prove you were never touched.
If any of this feels unfamiliar territory, our e-commerce security checklist for small stores covers the baseline hygiene that makes incidents like this survivable rather than fatal.
If you find something
Do not start deleting. Image the database and the web root read-only first, because the moment you clean up you destroy the evidence that tells you what else was taken.
Then reset every password, administrators first. The SQL injection alone can read the wp_users table, which means an attacker may be holding your password hashes even if they never got further. Rotate the database password, API keys and SMTP credentials while you are in there.
One step most people miss: your backups. A snapshot taken while the site was compromised still contains the attacker’s admin account. Restoring it reinstalls the backdoor. Clean the live site, then take a fresh backup, then delete the snapshots from the exposure window.
Card data is its own category of problem. If your checkout runs on the same install, the exposure window matters for compliance, not just cleanup. We covered the payment-page side of this in our look at the fake Stripe form skimming WooCommerce carts.
The uncomfortable part
A researcher plus a frontier model turned a subtle query-building flaw into a working pre-auth RCE against the most widely deployed CMS on the internet in ten hours. Knott told Dark Reading that watchTowr reproduced CVE-2026-63030 within minutes of disclosure using AI assistance. The gap between “advisory published” and “mass exploitation” is now measured in hours, not the weeks small store owners have quietly relied on for years.
That changes the maths on hosting. Managed platforms that patch core within hours and keep off-site, versioned backups are worth more than they were last year, which is why we compare them in detail in our WordPress hosting guide for e-commerce. It also changes the maths on monitoring. If your only detection method is noticing that something looks wrong on the front end, you will find out last.
The takeaway is simple enough to act on today: verify the version number yourself, read your administrator list, and treat the two weeks before you patched as a window you have to account for rather than assume away.
Sources
- VulnCheck, “WP2Shell Vulnerabilities: CVE-2026-60137 and CVE-2026-63030,” July 17, 2026 — vulncheck.com
- Wiz Research, “Exploitation in the Wild of wp2shell,” July 20, 2026 — wiz.io
- Eye Security, “wp2shell: incident response guide,” July 20, 2026 — labs.eye.security
- Dark Reading, “‘WP2Shell’ Opens Millions of WordPress Sites to Remote Takeover,” July 20, 2026 — darkreading.com
- WordPress.org, “WordPress 7.0.2 Release,” July 17, 2026 — wordpress.org
- Searchlight Cyber research write-up and checker — wp2shell.com
- NVD entries for CVE-2026-60137 and CVE-2026-63030
Last reviewed: August 1, 2026
Affiliate disclosure: some links on this site are affiliate links. If you buy through them we may earn a commission at no extra cost to you. This does not influence which products or security guidance we recommend.
