wp2shell WordPress RCE Exploited After Emergency Patch

Attackers have started targeting two recently patched WordPress Core vulnerabilities that can be chained to execute code without authentication. Public proof-of-concept exploits appeared shortly after WordPress released emergency security updates.

The attack chain, known as wp2shell, works against affected WordPress 6.9 and 7.0 installations without requiring a valid account, vulnerable plugin, or user interaction. A successful attacker could access database content and gain control of the affected website.

Administrators should update WordPress 6.8 sites to version 6.8.6, WordPress 6.9 sites to 6.9.5, and WordPress 7.0 sites to 7.0.2. WordPress 7.1 Beta users should install Beta 2 or a later release.

WordPress released an emergency security update

WordPress published its WordPress 7.0.2 security release on July 17, 2026. The update addresses one critical issue and one high-severity vulnerability.

The wp2shell attack chain combines a SQL injection flaw with a REST API batch-route confusion bug. The vulnerabilities have separate CVE identifiers because they affect different parts of WordPress Core.

WordPress enabled forced updates through its auto-update system for sites running affected versions. Administrators should still check every site manually because automatic updates can fail or remain disabled in some environments.

wp2shell combines two WordPress Core vulnerabilities

CVE-2026-60137 is an unauthenticated SQL injection vulnerability in the author__not_in parameter handled by the WP_Query class. It affects WordPress versions 6.8.0 through 6.8.5, 6.9.0 through 6.9.4, and 7.0.0 through 7.0.1.

CVE-2026-63030 involves route confusion in the WordPress REST API batch endpoint. It can let a sub-request reach an unintended callback with validation and route restrictions out of sync.

When attackers combine the two weaknesses on WordPress 6.9 or 7.0, they can move from an anonymous request to SQL injection and remote code execution. The Searchlight Cyber wp2shell report says the attack works against a stock installation without additional plugins.

Vulnerability	Type	Affected branches	Potential impact
CVE-2026-60137	SQL injection	WordPress 6.8, 6.9, and 7.0	Unauthorized database access
CVE-2026-63030	REST API batch-route confusion	WordPress 6.9 and 7.0	Enables the unauthenticated RCE chain
wp2shell chain	Combined exploitation	Affected WordPress 6.9 and 7.0 releases	Remote code execution and site takeover

A persistent object cache changes exposure

Searchlight Cyber initially described the attack as having no preconditions on a stock WordPress installation. Later analysis added an important technical condition affecting the RCE path.

According to Cloudflare’s WordPress vulnerability analysis, CVE-2026-63030 can enable unauthenticated code execution through the REST API batch endpoint when the site does not use a persistent object cache.

Many standard WordPress installations do not use a persistent object cache by default. Administrators should therefore update based on the installed WordPress version instead of attempting to determine safety through cache configuration alone.

Which WordPress versions are affected?

The two vulnerabilities cover different version ranges. WordPress 6.8 contains the SQL injection bug but not the REST API route confusion required for the complete wp2shell RCE chain.

WordPress version	SQL injection status	wp2shell RCE status	Required update
Earlier than 6.8.0	Not affected by these CVEs	Not affected	Move to a maintained release
6.8.0 through 6.8.5	Affected	Not affected by the complete chain	Update to 6.8.6 or later
6.9.0 through 6.9.4	Affected	Affected	Update to 6.9.5 or later
7.0.0 through 7.0.1	Affected	Affected	Update to 7.0.2 or later
WordPress 7.1 Beta 1	Affected	Affected	Update to 7.1 Beta 2 or later

The official WordPress release announcement confirms that versions before WordPress 6.8 are not affected by these two vulnerabilities.

However, running an older release does not provide a safe long-term alternative. Unsupported and outdated WordPress branches may contain other vulnerabilities and no longer receive complete security maintenance.

Public exploits appeared after disclosure

Searchlight Cyber withheld its detailed exploit method to give administrators time to update. However, WordPress Core is open source, allowing other researchers to compare the patched and vulnerable code.

Public proof-of-concept projects appeared shortly after the security release. Some demonstrated database access, password-hash extraction, or the wider route toward code execution.

The Patchstack vulnerability entry now classifies CVE-2026-63030 as known to be exploited. Other security companies have also reported attempts against honeypots and incident-response activity involving vulnerable sites.

How attackers could use wp2shell

Remote code execution can give an attacker extensive control over the WordPress application and its hosting account, depending on the permissions assigned to the web-server process.

A successful attacker could potentially:

• Read or modify WordPress database content
• Steal administrator password hashes
• Create unauthorized administrator accounts
• Upload web shells or other malicious PHP files
• Redirect visitors to phishing or malware pages
• Inject malicious JavaScript into published content
• Access WooCommerce customer and order information
• Use the server to attack other systems

Access to WordPress does not automatically provide root or full server privileges. However, a compromised site can still expose sensitive data, damage visitors, harm search rankings, and provide a foothold for further attacks.

WordPress forced automatic security updates

WordPress took the unusual step of initiating forced updates for affected versions because of the severity and broad reach of the vulnerabilities.

Sites that allow automatic background updates should begin receiving the appropriate patched release. Hosting providers may also apply the updates through their own management platforms.

Administrators should verify the installed version instead of assuming the update succeeded. Filesystem permissions, disabled update settings, failed cron tasks, custom deployment systems, or managed-hosting controls can prevent an automatic update.

How to update WordPress manually

Administrators with dashboard access can install the security release directly from WordPress.

1. Sign in to the WordPress administration dashboard.
2. Open Dashboard and select Updates.
3. Check the currently installed WordPress version.
4. Click Update Now if a patched release is available.
5. Confirm the new version after the update completes.
6. Test the website and essential plugins.
7. Clear application, server, and CDN caches.

Organizations that manage WordPress through Composer, WP-CLI, container images, or automated deployment pipelines should update the relevant package or image and redeploy the site.

Searchlight Cyber provides a public checker

Searchlight Cyber released a free online tool that tests whether a WordPress installation appears vulnerable. The company explains the checker and temporary mitigations in its wp2shell security advisory.

A scanner result should support version verification, not replace it. Reverse proxies, web application firewalls, caching systems, or network errors may affect the result.

The safest check remains confirming that the site runs WordPress 6.8.6, 6.9.5, 7.0.2, 7.1 Beta 2, or a later secure release for its branch.

Temporary protections for sites that cannot update

Administrators who cannot update immediately can block anonymous access to the vulnerable REST API batch route. These controls may disrupt legitimate integrations that depend on the WordPress REST API.

• Block /wp-json/batch/v1 at the web application firewall
• Block requests using rest_route=/batch/v1
• Require authentication for the REST API batch route
• Temporarily block anonymous REST API access
• Monitor rejected requests for repeated exploitation attempts

Both route formats must be covered because WordPress can receive REST requests through standard paths or the rest_route query parameter.

These measures reduce exposure but do not repair the vulnerable WordPress code. Administrators should remove temporary restrictions only after applying the official security update and confirming that the patch succeeded.

Cloudflare deployed WAF rules for both CVEs

Cloudflare deployed new managed rules on July 17 to detect and block traffic targeting the SQL injection and RCE paths. The company says the protections cover proxied WordPress traffic on free and paid plans.

The Cloudflare WAF guidance recommends checking for ruleset overrides that may have changed the action from Block to Log.

WAF protection adds an important layer during deployment, but it cannot guarantee that every exploit variation will fail. Updating WordPress remains the primary remediation.

How to investigate a potentially compromised site

Sites that remained unpatched after public exploit code became available should receive a security review, especially if logs show requests to the affected batch endpoint.

1. Preserve web, WAF, authentication, and hosting logs.
2. Search for suspicious batch REST API requests.
3. Review recently created WordPress administrator accounts.
4. Inspect recently modified PHP files and active plugins.
5. Check wp-content/uploads for unexpected executable files.
6. Review scheduled tasks, must-use plugins, and theme files.
7. Rotate WordPress, database, hosting, SSH, and API credentials.
8. Restore from a verified clean backup when compromise is confirmed.

Changing passwords alone will not remove a web shell, malicious plugin, modified theme, or persistent administrator account. Administrators should identify and remove every persistence mechanism before returning the site to service.

Patchstack urges immediate mitigation

The Patchstack wp2shell record advises site owners to update immediately and lists WordPress 7.0.2 as the patched release for the 7.0 branch.

Sites protected by security plugins or external WAFs should still install the official update. Firewall rules can reduce risk while an update rolls out, but they do not correct the underlying Core vulnerabilities.

Hosting providers and agencies should inventory every managed WordPress site, including staging systems, development domains, abandoned installations, and sites hidden behind nonstandard hostnames.

Researchers credited for the WordPress fixes

WordPress credited Adam Kues of Assetnote and Searchlight Cyber with reporting the REST API batch-route confusion and SQL injection chain that led to remote code execution.

The WordPress security team separately credited TF1T, dtro, and haongo with jointly reporting the SQL injection issue tracked as CVE-2026-60137.

The appearance of public exploits and reported attack attempts makes immediate patch verification essential. Administrators should not rely solely on forced updates, a WAF, or a vulnerability scanner when they can confirm the installed WordPress version directly.

FAQ