WordPress 7.1.2 is a critical core security release (CVE-2026-87902). 7.1.1 patched Click2Shell and Comment2Shell. July leftover-access checks still apply.
Topics Hardening & checklists
Updated Published
WordPress 7.1.2: critical template-resolution issue
WordPress shipped 7.1.2 on 22 Sep as a security release for a critical core issue (CVE-2026-87902). An unauthenticated attacker can, under certain conditions, make page template resolution include a chosen readable PHP file outside the active theme. If server and theme pre-conditions are met, that can reach RCE. Confirm every install is on 7.1.2 or your branch's security backport. WordPress listed 7.0.6, 6.9.9, 6.8.10, and older branches through 4.7.37. This is separate from July wp2shell and from Click2Shell and Comment2Shell in 7.1.1. See the September lead at the top of this page.
New core issues in 7.1.1: Click2Shell and Comment2Shell
Separate from the July wp2shell chain. WordPress 7.1.1 (17 Sep) patched Click2Shell and Comment2Shell. Comment2Shell is CVE-2026-93485. Full PoCs and mainstream write-ups landed 21-22 Sep. Confirm every install is on 7.1.1 or your branch's security backport, review unexpected inactive themes, and tighten comment moderation. See the September lead at the top of this page. July leftover-access checks below still apply.
Almost two months later: leftover access is still the remaining job
WordPress shipped 6.8.6, 6.9.5, and 7.0.2 on July 17. That is almost two months ago. FortiGuard Labs still lists the WP2Shell outbreak alert. No new CVE for this chain. Later WordPress releases such as 7.0.4 and 7.1 are separate security work. They do not replace the leftover-access check. Confirm every install is on a fixed version, including quiet sites and ones where auto-updates were blocked, then check Users, must-use plugins, and PHP in uploads. If a scanner now says core files were modified, treat that as a checksum mismatch until the diff says otherwise. A checker tells you if the hole is still open. It does not prove leftover access is gone.
End of August: nearly seven weeks later, leftover access still matters
WordPress shipped 6.8.6, 6.9.5, and 7.0.2 on July 17. That is nearly seven weeks ago. FortiGuard Labs still lists the WP2Shell outbreak alert, and they refreshed their public outbreak guidance on August 26. No new CVE today. The remaining work is the same: confirm every install is on a fixed version, including quiet sites and ones where auto-updates were blocked, then check 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 you manage client sites, a month-end Monday is a good day to finish the ones nobody opened in August.
Nearly six weeks later: leftover access is still the job
WordPress shipped 6.8.6, 6.9.5, and 7.0.2 on July 17. FortiGuard Labs still lists the WP2Shell outbreak alert. No new CVE today. Confirm every install is on a fixed version, including quiet sites and ones where auto-updates were blocked. Then check 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.
Sunday, five weeks later: quiet sites still count
WordPress shipped 6.8.6, 6.9.5, and 7.0.2 on July 17. That is five weeks ago today. FortiGuard Labs still lists the WP2Shell outbreak alert and continues to report exploitation attempts against WordPress core. Weekends are when agencies and site owners often stop checking. Leftover access on a quiet install does not pause for Saturday. Confirm the version on every site, including ones nobody logged into this week. Then Users, must-use plugins, and PHP in uploads. Eye Security's Compromise Scanner for wp2shell reports 2,000+ active installs on WordPress.org as a read-only forensic helper after you update. A clean scan is not proof. Update core first.
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.
The current September work is WordPress 7.1.2 (or the matching security backport on your branch). 7.1.1 closed Click2Shell and Comment2Shell. The July wp2shell hole closed in 6.8.6, 6.9.5, and 7.0.2. Updating closes known holes. 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 [email protected]), @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 a scanner later says core files were modified, that is a checksum mismatch, not a new wp2shell CVE. Open the diff before you ignore it. After this incident, a quiet edit in wp-includes is often leftover access. See WordPress core files were modified.
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 [email protected]), @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. 7.1.2 (22 Sep) is a separate critical core issue (CVE-2026-87902) in page template resolution. Click2Shell and Comment2Shell were patched in 7.1.1 on 17 Sep. wp2shell is the July chain (CVE-2026-63030 and CVE-2026-60137). Same first job: update core, then check the site.
No. 7.1.2 (or your branch’s security backport) closes the 22 Sep hole, and includes the 7.1.1 Click2Shell and Comment2Shell fixes. It does not prove leftover access from July is gone. Keep the checklist on this page.
No. wp2shell is the July core chain (CVE-2026-63030 and CVE-2026-60137). Click2Shell and Comment2Shell were patched in WordPress 7.1.1 on 17 Sep 2026. Comment2Shell is CVE-2026-93485. Different bugs. Same first job: update core, then check the site.
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.
Not a new CVE. It means a WordPress core file no longer matches the official copy. After wp2shell that is often leftover access. Open the diff before you ignore it. Full diagnostic: WordPress core files were modified.
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.1.2, the 7.1.1 release, the 7.0.2 release, 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.
wpautop)Found this useful? Share it.