--- title: "wp2shell: Critical WordPress core vulnerability actively exploited" canonical: https://wpsecurityninja.com/wp2shell/ ---

Fixed versions

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.

60-second check

  1. WordPress version is 6.8.6, 6.9.5, 7.0.2, or newer (Dashboard → Updates, not only “you have the latest”).
  2. Users: no administrators you did not create, and no odd emails such as @wp2shell.invalid or @wp2shell.local.
  3. Plugins: nothing new, renamed, or unknown.
  4. wp-content/mu-plugins/: unexpected files (these often hide from the Plugins list).
  5. Uploads and cache: no unexplained PHP files.

If any of those look off, keep going through the full checklist below. Do not stop at the version number.

## Who is affected?
| 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 |

Older WordPress

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.

If you manage many sites

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.

## What site owners should do now ### Do now 1. Check the installed WordPress version (Dashboard → Updates, or the About WordPress screen / admin footer). 2. Update to WordPress **6.8.6**, **6.9.5**, **7.0.2**, or a newer secure release on your branch. 3. Verify the update finished. Dashboard → Updates should show **6.8.6**, **6.9.5**, **7.0.2**, or newer, not only a generic “you have the latest” message. ### Then check for compromise 4. Check for unexpected administrator accounts, including odd usernames or email addresses you did not create. Public PoCs have used login prefixes such as `wp2_` and `w2s_`, and emails on `@wp2shell.invalid` (including addresses such as `site_admin@wp2shell.invalid`), `@wp2shell.local`, and `@wp2shell.shellcode.lol`. 5. Review application passwords on every administrator (Users → Profile / Application Passwords). A rogue admin is easy to spot. An application password on a legitimate account can survive a rushed cleanup. 6. Review recently installed, uploaded, or modified plugins, including anything that looks like a renamed lookalike. 7. Inspect `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. 8. Check for unexplained PHP files under uploads, cache, and other writable directories. 9. Review hosting, firewall, WordPress, and application logs around the period the site may have been vulnerable. Pay attention to traffic hitting the REST API batch endpoint (`/wp-json/batch/v1` or `?rest_route=/batch/v1`), especially unusual Multi-Status (HTTP 207) responses. 10. Investigate unexplained redirects, scheduled tasks (including server cron), outbound requests, or newly created files. 11. Change sensitive credentials when there are signs of compromise. The SQL-injection path can expose password hashes, so force password resets for administrators (and preferably all users) if the site was exposed before patching. Also rotate salts / force logout of all sessions when compromise is suspected. 12. Restore from a known-clean backup or get professional help when compromise is confirmed. Do not assume a backup taken after July 17 is clean. 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.

## Patched is not the same as clean 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.

Rule of thumb

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.

## What is wp2shell? **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: 1. A WordPress REST API batch-processing issue can cause validation and execution to become associated with different route handlers. 2. That confusion can expose a separate SQL-injection weakness in `WP_Query`. 3. When chained, the vulnerabilities can let someone take over an affected site without logging in. After that, attackers often install malware: webshells, malicious plugins, or both. 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. ## Indicators worth reviewing Treat these as areas to investigate, not proof that a website has been compromised: - Unexpected WordPress administrator accounts (including unusual login names or email domains) - Admin usernames starting with `wp2_` or `w2s_` (reported PoC patterns) - Admin emails using `@wp2shell.invalid` (including addresses such as `site_admin@wp2shell.invalid`), `@wp2shell.local`, or `@wp2shell.shellcode.lol` - Unexpected application passwords on otherwise legitimate administrator accounts - Recently activated, uploaded, or installed plugins, including lookalike or unknown plugin folders - Unexpected files in `wp-content/mu-plugins/` (must-use plugins may hide from the normal plugin list) - Modified theme or plugin PHP files - Unexpected PHP files in uploads, cache, or other writable directories - Encoded or suspicious options / transients that mimic site-health names - Requests involving the WordPress REST API batch endpoint (`/wp-json/batch/v1` or `?rest_route=/batch/v1`), especially HTTP 207 Multi-Status responses - User-agent strings that mention `wp2shell` or `rezwp2shell` (reported as tool signatures) - Unexplained WordPress cron events or server crontab entries that restore files - Unfamiliar redirects or injected JavaScript - New outbound network connections - Changes to `wp-config.php`, `.htaccess`, server configuration, or must-use plugins - Security alerts around the time the site remained vulnerable

Partial exploit warning

Bitdefender 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](https://wpsecurityninja.com/malware-scanner/) and [security tests](https://wpsecurityninja.com/security-tests/) can help surface suspicious files and configuration issues. For confirmed compromise, [professional cleanup](https://wpsecurityninja.com/consultation/) is often the safer path. ## Does a firewall protect the website? A web application firewall may block known attack patterns and reduce exposure while you update. Useful, but: - A firewall is not a substitute for installing the WordPress update. - Temporarily blocking anonymous access to the REST batch endpoint at the edge can buy time while you patch. It is not a permanent fix. - Rules differ between vendors and hosting providers. - Confirm both the WordPress version and any protection status. - A firewall cannot clean a site that was already compromised. 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. ## Frequently asked questions ### Is wp2shell a plugin vulnerability? 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. ### Which WordPress versions are affected? 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. ### Did WordPress update automatically? 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. ### How can I check my WordPress version? 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. ### Is there a wp2shell checker? There are a few, and they answer different questions. Searchlight Cyber’s [wp2shell.com](https://wp2shell.com/) checker tests whether a site is still vulnerable to the hole. After you update, Eye Security’s [Compromise Scanner for wp2shell](https://wordpress.org/plugins/compromise-scanner-for-wp2shell/) and InstaWP’s [wp2shell-scan](https://github.com/InstaWP/wp2shell-scan) look for known leftover traces. None of them prove a site is clean. Update WordPress first, then use them as extra eyes. ### Does updating prove my website is clean? 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. ### Should I disable the REST API? 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. ### Does a security plugin replace the update? No. Update WordPress first. Security plugins can help with detection, monitoring, and layered protection, but they do not replace applying the core security releases. ### Can a scanner prove the site is clean? 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. ### What should I do if I find an unknown administrator? 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](https://wpsecurityninja.com/consultation/). ### I found an admin email like site_admin@wp2shell.invalid. Is that wp2shell? 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. ### Are WordPress versions before 6.8 safe? 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. ### Where can I follow new developments? Watch the [WordPress.org news post for 7.0.2](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/), the [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-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.

## Sources - [WordPress 7.0.2 Maintenance and Security Release](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/). WordPress.org News. July 17, 2026 - [WordPress version 7.0.2 documentation](https://wordpress.org/documentation/wordpress-version/version-7-0-2/). WordPress.org Documentation - [wp2shell: Pre Authentication RCE in WordPress Core](https://slcyber.io/research-center/wp2shell-pre-authentication-rce-in-wordpress-core/). Searchlight Cyber. July 17, 2026 - [wp2shell.com checker](https://wp2shell.com/). Searchlight Cyber. Public vulnerability checker - [Unauthenticated SQL Injection in WordPress Core Fixed in 7.0.2](https://patchstack.com/articles/unauthenticated-sql-injection-in-wordpress-core-fixed-in-7-0-2/). Patchstack - [wp2shell WordPress Exploit Technical Analysis and Real Attack Data](https://www.wordfence.com/blog/2026/07/wp2shell-wordpress-exploit-technical-analysis-and-real-attack-data/). Wordfence. July 2026 - [wp2shell: incident response guide](https://labs.eye.security/wp2shell-defenders-guide/). Eye Security - [wp2shell: WordPress Core Pre-Auth RCE FAQ](https://www.tenable.com/blog/wp2shell-cve-2026-63030-cve-2026-60137-frequently-asked-questions-about-remote-code-execution). Tenable. July 20, 2026 - [CISA Adds Four Known Exploited Vulnerabilities to Catalog](https://www.cisa.gov/news-events/alerts/2026/07/21/cisa-adds-four-known-exploited-vulnerabilities-catalog/). CISA. July 21, 2026 - [Exploitation in the Wild of wp2shell](https://www.wiz.io/blog/wp2shell-cve-2026-63030-cve-2026-60137). Wiz Research - [Critical wp2shell WordPress flaws exploited to install webshells](https://www.bleepingcomputer.com/news/security/critical-wp2shell-wordpress-flaws-exploited-to-install-webshells/). BleepingComputer. July 21, 2026 - [Attacks against the unauthenticated RCE chain "wp2shell" targeting WordPress Core](https://www.cscloud.co.jp/news/report/202608049157/?lang=en). Cyber Security Cloud. August 4, 2026 - [WP2Shell RCE Outbreak Alert](https://fortiguard.fortinet.com/outbreak-alert/wp2shell-rce). FortiGuard Labs - [Technical Advisory: wp2shell, Unauthenticated Remote Code Execution and Full Site Takeover in WordPress Core](https://businessinsights.bitdefender.com/technical-advisory-wp2shell-unauthenticated-remote-code-execution-full-site-takeover-wordpress-core). Bitdefender. July 27, 2026 - [The WordPress Chain Massacre](https://blog.calif.io/p/the-wordpress-chain-massacre). Calif. August 5, 2026 - [Inside a wp2shell WordPress Compromise and Recovery](https://www.inmotionhosting.com/blog/inside-wp2shell-wordpress-compromise-recovery/). InMotion Hosting. August 2026 - [Forensic analysis of a wp2shell WordPress compromise: two operators and four persistence locations](https://dev.to/zft9xgy/forensic-analysis-of-a-wp2shell-wordpress-compromise-two-operators-and-four-persistence-locations-4cif). Independent forensic write-up. July 2026 - [wp2shell-scan](https://github.com/InstaWP/wp2shell-scan). InstaWP. Read-only compromise helper for one site or many - [Inside Our wp2shell Response](https://instawp.com/wp2shell-rce-cve-2026-63030-7-0-2/). InstaWP. July 2026 - [wp2shell: detecting WordPress pre-auth RCE end-to-end](https://www.elastic.co/security-labs/wp2shell-wordpress-rce-detection-elastic-defend). Elastic Security Labs - [Compromise Scanner for wp2shell](https://wordpress.org/plugins/compromise-scanner-for-wp2shell/). Eye Security. Read-only WordPress.org plugin for known traces ### Reference IDs - CVE-2026-60137, CVE-2026-63030 - CVE-2026-31431 (Copy Fail, post-exploitation host escalation research) - GHSA-fpp7-x2x2-2mjf, GHSA-ff9f-jf42-662q