wp2shell is a WordPress core vulnerability (CVE-2026-63030, CVE-2026-60137). Confirm 6.8.6, 6.9.5, or 7.0.2, then check leftover admins and what a scanner can actually prove.
Topics Hardening & checklists
Updated Published
More than a month later: leftover access is the remaining job
WordPress shipped 6.8.6, 6.9.5, and 7.0.2 on July 17. That is more than a month ago. FortiGuard Labs still lists scanning against WordPress core. The news is not new. What still goes wrong is leftover access on sites that were patched late, or never checked after the update. Confirm the version first. Then Users, must-use plugins, and PHP in uploads. A checker tells you if the hole is still open. It does not prove leftover access is gone. If a site already looks wrong, treat that as cleanup work, not a dashboard glance.
Monday after one month: check the sites nobody opened last week
WordPress shipped 6.8.6, 6.9.5, and 7.0.2 on July 17. That was one month ago yesterday. FortiGuard Labs still lists scanning against WordPress core. Monday is when agencies and freelancers usually open the quiet installs: the ones auto-updates missed, and the ones nobody logged into last week. Confirm the version first. Then Users, must-use plugins, and PHP in uploads. A checker tells you if the hole is still open. It does not prove leftover access is gone. If a site already looks wrong, treat that as cleanup work, not a dashboard glance.
One month later: if you found a strange admin email, start here
WordPress shipped 6.8.6, 6.9.5, and 7.0.2 on July 17. That is one month ago today. FortiGuard Labs still lists scanning against WordPress core. What still turns up is leftover access: an administrator you did not create, often with an email on @wp2shell.invalid or @wp2shell.local. Confirm the version on every site, including ones nobody opened this week. Then check Users, must-use plugins, and PHP in uploads. Searchlight Cyber’s wp2shell.com checker tells you if a site is still vulnerable. Eye Security’s Compromise Scanner looks for known traces after you update. Neither one finishes cleanup, and a clean result is not a guarantee.
Saturday check: the sites nobody opened this week still count
It is almost four weeks since WordPress shipped 6.8.6, 6.9.5, and 7.0.2. FortiGuard Labs still lists scanning against WordPress core. Weekends are when agencies and site owners usually stop looking. That is also when leftover access on a quiet install keeps working. Confirm the version on every site, including ones nobody logged into this week. Then check Users, must-use plugins, and PHP in uploads. Eye Security published a read-only Compromise Scanner for wp2shell on WordPress.org that looks for known database and plugin traces. A clean result is not a guarantee. A match is not automatic proof. Update core first, then use helpers as extra eyes.
Almost four weeks later: check every site, including the ones nobody logged into
WordPress shipped 6.8.6, 6.9.5, and 7.0.2 on July 17. FortiGuard Labs still reports scanning against WordPress core. Most people who were going to hear the news already did. What still goes wrong is skipping installs where auto-updates were blocked, or calling a site clean after a dashboard glance. If you manage client sites, check each one, including the dormant ones. InstaWP published a read-only wp2shell-scan helper, and Elastic Labs published detection notes for teams that already collect logs. Those tools can surface traces. They do not replace the WordPress update, and they do not finish cleanup on a site that was already owned.
Forensics: attackers can stay active after the site reaches a fixed WordPress version
A forensic write-up from a July compromise describes one site taken over by at least two different attacker groups, each with its own way of staying in. Activity continued after WordPress was updated to 7.0.2. The leftovers were not only rogue admins and webshells in the site files. Investigators also found host-level footholds such as system crontab entries and payloads outside the WordPress folder. Takeaway: confirm every install is on 6.8.6, 6.9.5, 7.0.2, or newer, then treat cleanup as a WordPress plus hosting check. FortiGuard Labs still reports scanning against WordPress core. If you manage many sites, verify versions one by one, including installs where automatic updates were blocked for stability.
Nearly a month later: scanning continues
It has been almost four weeks since WordPress shipped 6.8.6, 6.9.5, and 7.0.2. FortiGuard Labs still reports wp2shell exploitation attempts against WordPress core. Confirm the version on every site you manage. A fixed version closes the known hole. It does not clean a site that was already compromised. Keep checking for rogue admins, must-use plugins, PHP in uploads, and leftover webshells.
Hosting forensics: a quick cleanup can leave the door open
InMotion Hosting published a report from real wp2shell compromises. Attackers went from the batch endpoint to a new admin and a malicious plugin in under 30 seconds. They stayed in through rogue admins, lookalike plugins, must-use plugin files that restore deleted malware, PHP under uploads, encoded options-table payloads, wp-config loaders, and cron. One site was cleaned of rogue admins and patched, then taken over again six days later through a leftover webshell. Another used a must-use credential stealer that hid from the mu-plugin list. Extra checks: look in wp-content/mu-plugins, review application passwords on real accounts, and treat a patched dashboard as closing the hole, not proof the compromise is gone. FortiGuard still reports ongoing exploitation attempts.
FortiGuard: thousands of attempts still blocked daily
FortiGuard Labs is still seeing wp2shell exploitation attempts against WordPress core. In one recent 24-hour window its IPS blocked 4,649 attempts, with about 88,452 detections over seven days. The highest recent volume involved Poland, Australia, Japan, the United States, and Turkey. Three weeks after the security releases, the reminder is the same: confirm every install is on 6.8.6, 6.9.5, 7.0.2, or newer, then check for compromise, including rogue administrators left by failed exploit runs.
Research chain shows a path from wp2shell past PHP hardening to Linux root
Calif published wp2root, a research chain that starts after wp2shell already has PHP execution. It uses a PHP memory-corruption path to get around disable_functions and similar interpreter limits, then Copy Fail (CVE-2026-31431) to reach fileless root without changing binaries on disk. This shows what is possible after a successful foothold. It is not a claim that this exact chain is already common in the wild. Practical takeaway: update WordPress, check for compromise, and do not assume PHP hardening alone contains the damage. Hosts should also apply kernel updates for CVE-2026-31431. FortiGuard Labs still reports thousands of exploitation attempts daily.
Failed exploit attempts can still leave rogue admins behind
Bitdefender MDR documented a wp2shell incident where the attack stalled twice after creating unauthorized w2s_-prefixed administrator accounts, with no plugin or webshell left behind. On the third attempt it succeeded, uploaded malicious plugin droppers, and deployed PHP webshells. The cleanup step only runs when the whole chain works, so an unknown admin can mean the site was targeted and the attacker may come back. Check Users for admins you did not create before deciding a patched site is clean.
Attack volume jumped the day the patches shipped
Cyber Security Cloud reported about 1.95 million batch-endpoint detections over nine days after disclosure, including a roughly 277x jump on the day the patches shipped. FortiGuard Labs still reports exploitation attempts worldwide. Same reminder: update and verify each install, then check for compromise.
More defender write-ups, and sharper compromise checks
Wordfence reports more than 11 million blocked exploit attempts against the chain. Eye Security, Tenable, Wiz, and others published defender guidance, including admin username and email patterns tied to public PoCs. Indicators and sources on this page were refreshed.
Attack data and leftover malware reporting refreshed
Wordfence published technical analysis and real attack data. Broader reporting confirms opportunistic webshell and malicious-plugin installs after a successful chain. Compromise checks and sources on this page were updated.
Advisory published
Initial advisory with affected versions, fixed releases, recommended checks, and primary sources.
Added to CISA Known Exploited Vulnerabilities Catalog
CISA added CVE-2026-63030 and CVE-2026-60137 to the KEV catalog based on evidence of active exploitation.
WordPress security releases published
WordPress 6.8.6, 6.9.5, and 7.0.2 were released with security fixes for the related core vulnerabilities.
Confirm that every WordPress install is on 6.8.6, 6.9.5, 7.0.2, or newer. Updating closes the known holes, but it does not by itself prove a previously exposed site is clean.
@wp2shell.invalid or @wp2shell.local.wp-content/mu-plugins/: unexpected files (these often hide from the Plugins list).If any of those look off, keep going through the full checklist below. Do not stop at the version number.
| WordPress branch | Exposure | Fixed version |
|---|---|---|
| 7.0 through 7.0.1 | Both vulnerabilities and complete attack chain | 7.0.2 |
| 6.9 through 6.9.4 | Both vulnerabilities and complete attack chain | 6.9.5 |
| 6.8 through 6.8.5 | Related SQL-injection vulnerability only | 6.8.6 |
| Earlier than 6.8 | Not affected by these two vulnerabilities | Upgrade to a currently supported branch |
Versions before 6.8 are not affected by these two vulnerabilities. That does not mean older or unsupported WordPress installs are generally safe. Unsupported branches still need a supported upgrade path.
WordPress 7.0.2 was released on July 17, 2026 and fixed one critical and one high-severity core issue. WordPress 6.9 is affected by both. WordPress 6.8 is affected only by the facilitated SQL-injection vulnerability. Because of the severity, WordPress enabled forced automatic updates for affected installations.
Verify each install, including sites nobody has logged into for months and sites where automatic updates were blocked for stability. One dashboard glance is not a portfolio check. WP-CLI (wp core version) or a hosting panel list is faster than opening every wp-admin. Searchlight Cyber’s wp2shell.com checker tests whether a site is still vulnerable. Helpers such as InstaWP’s read-only wp2shell-scan and Eye Security’s Compromise Scanner for wp2shell can flag known traces after you update. They do not replace the core update, and they do not finish cleanup.
wp2_ and w2s_, and emails on @wp2shell.invalid (including addresses such as site_admin@wp2shell.invalid), @wp2shell.local, and @wp2shell.shellcode.lol.wp-content/mu-plugins/. Must-use plugins load automatically, often do not appear in the normal Plugins list, and cannot be deactivated from the dashboard. Hosting forensics after wp2shell found guardians and credential stealers here./wp-json/batch/v1 or ?rest_route=/batch/v1), especially unusual Multi-Status (HTTP 207) responses.Changing passwords alone does not clean a compromised site. If you find clear signs of intrusion, treat credentials, files, and plugins as one problem, not separate chores.
If this already looks wrong
You do not have to finish cleanup alone. If you found an unknown admin, odd plugins, or PHP where it should not be, we can help with cleanup and next steps. Use the checklist first so you know what you are looking at.
Installing the update stops the known vulnerability from being used going forward. It does not undo anything an attacker may have done while the site was still vulnerable.
A fixed version in the dashboard is not the same as finishing a security check. Investigators have documented sites that looked clean after a quick cleanup, then were re-owned days later through a leftover webshell or a must-use plugin that restored files.
If you updated quickly and nothing looks wrong after the 60-second check, you may not need a full incident response. If you find suspicious accounts, files, plugins, redirects, or logs, dig deeper, including host cron and files outside the WordPress folder.
Update first. Then decide how deep to investigate based on what you find in users, plugins, files, and logs. PHP hardening helps, but it is not a substitute for patching WordPress or reviewing a site that was exposed.
wp2shell is the informal name for a WordPress core vulnerability chain, not a plugin bug. The two CVE IDs are CVE-2026-63030 (REST API batch route/handler confusion) and CVE-2026-60137 (SQL injection in WP_Query). Together they can let someone take over an affected site without logging in.
At a high level:
WP_Query.Wordfence recorded probing of WordPress REST API traffic on July 17, 2026, with a clear SQL-injection attempt minutes later. Later reporting from multiple vendors describes opportunistic campaigns that install webshells and malicious plugins after a successful chain. No exploit steps here on purpose.
Treat these as areas to investigate, not proof that a website has been compromised:
wp2_ or w2s_ (reported PoC patterns)@wp2shell.invalid (including addresses such as site_admin@wp2shell.invalid), @wp2shell.local, or @wp2shell.shellcode.lolwp-content/mu-plugins/ (must-use plugins may hide from the normal plugin list)/wp-json/batch/v1 or ?rest_route=/batch/v1), especially HTTP 207 Multi-Status responseswp2shell or rezwp2shell (reported as tool signatures)wp-config.php, .htaccess, server configuration, or must-use pluginsBitdefender MDR saw wp2shell fail twice while still creating unauthorized w2s_ administrators, with no webshell or malicious plugin left behind. The third attempt succeeded and deployed droppers. An unknown admin is a serious indicator even when the file system looks clean.
If you still have admin access, a malware scan and security tests can help surface suspicious files and configuration issues. For confirmed compromise, professional cleanup is often the safer path.
A web application firewall may block known attack patterns and reduce exposure while you update. Useful, but:
A security plugin does not replace applying the official WordPress security releases for this issue. WP Security Ninja can still help with monitoring and scanning after you update.
No. It is a WordPress core vulnerability chain (CVE-2026-63030 and CVE-2026-60137). Plugins and themes are not the root cause of these two issues, though a compromised site may still show malware afterward: malicious plugins, webshells, or file changes.
WordPress 7.0 through 7.0.1 and 6.9 through 6.9.4 are affected by both issues in the chain. If you are still on 6.9.4 or 7.0.1, you are on the last vulnerable release of that branch. WordPress 6.8 through 6.8.5 is affected by the related SQL-injection vulnerability only. Fixed releases are 7.0.2, 6.9.5, and 6.8.6.
WordPress enabled forced automatic updates for affected installations because of the severity. You should still verify that every site reached a fixed version. Automatic updates can fail on some hosts, locked files, or heavily customized setups.
In wp-admin, open Dashboard → Updates, or check the version shown on the About WordPress screen / admin footer (depending on your setup). Hosting panels and WP-CLI (wp core version) also report it.
There are a few, and they answer different questions. Searchlight Cyber’s wp2shell.com checker tests whether a site is still vulnerable to the hole. After you update, Eye Security’s Compromise Scanner for wp2shell and InstaWP’s wp2shell-scan look for known leftover traces. None of them prove a site is clean. Update WordPress first, then use them as extra eyes.
No. Updating closes the known vulnerabilities going forward. It does not undo earlier unauthorized changes. Investigate if you see suspicious accounts, files, plugins, redirects, or logs.
Disabling the REST API is not the recommended fix and can break legitimate features. Install the official security update for your WordPress branch instead. If you cannot update immediately, a temporary edge rule against anonymous batch REST access is a bridge, not a replacement for the core release.
No. Update WordPress first. Security plugins can help with detection, monitoring, and layered protection, but they do not replace applying the core security releases.
No. Read-only helpers such as Eye Security’s Compromise Scanner for wp2shell and InstaWP’s wp2shell-scan can flag known traces. A clean result is not a guarantee. A match still needs a human check. Update WordPress first, then use scanners as extra eyes.
Treat it as a serious indicator. Do not only delete the user and move on. Investigate how it was created, review plugins and file changes, rotate credentials, and consider a full malware review or cleanup help.
Treat it as a serious indicator, not automatic proof. Public PoCs have used emails on @wp2shell.invalid, @wp2shell.local, and @wp2shell.shellcode.lol, plus login prefixes such as wp2_ and w2s_. Confirm the WordPress version, then go through the checklist: Users, application passwords, must-use plugins, and PHP in uploads.
They are not affected by these two specific vulnerabilities. That is not the same as being secure or supported. Unsupported versions still need upgrading to a currently maintained branch.
Watch the WordPress.org news post for 7.0.2, the CISA KEV catalog, and this advisory page. We update the Latest developments section when something material changes.
After you update
Keeping WordPress updated is the first line of defense. If you need cleanup help, we can help. When you are ready for extra monitoring, WP Security Ninja can review configuration, watch security events, and spot suspicious changes.
Found this useful? Share it.