wp2shell: The WordPress Core Flaw That Turns an Anonymous Request Into Remote Code Execution

WordPress patched a critical core vulnerability chain affecting versions 6.9 and 7.0, showing why even a clean installation with no plugins can become exposed when the bug is in the platform itself.

WordPress security incidents usually begin with a familiar question:

Which plugin was vulnerable?

That question does not work for wp2shell.

This time, the issue is not a theme. It is not a page builder. It is not a caching plugin. It is not an abandoned extension installed years ago and forgotten.

The issue is in WordPress Core.

That is why wp2shell matters.

According to the official WordPress release notes and security reporting, WordPress shipped emergency security updates for WordPress 6.9.5 and WordPress 7.0.2 to address a vulnerability chain that can lead to unauthenticated remote code execution, or pre-auth RCE, against affected WordPress sites. The issue has been associated with the name wp2shell and is tracked through two CVEs: CVE-2026–60137 and CVE-2026–63030.

The important point is simple: a bare WordPress installation, with no vulnerable plugin required, can be exposed if it is running an affected version.

That changes the risk model.

Many WordPress site owners focus on plugin hygiene, and rightly so. Plugins remain one of the most common sources of WordPress compromise. But wp2shell is a reminder that the core platform itself must also be patched quickly, especially when exploit details become public.

This is not a theoretical issue for administrators, hosting providers, agencies, bloggers, publishers, e-commerce owners, and managed service providers.

A working proof-of-concept has reportedly become public, and once exploit logic is available, the window between disclosure and mass scanning can shrink quickly. Searchlight Cyber also made a checker available for site owners through the wp2shell disclosure site.

The defensive message is clear: check the version, update immediately, and do not assume that automatic updates already solved the problem.

What Is wp2shell?

wp2shell is the name given to a WordPress Core vulnerability chain that can allow an unauthenticated attacker to reach remote code execution on affected sites.

It is not one bug.

It is a chain of two flaws.

The first is CVE-2026–60137, a SQL injection vulnerability in WordPress Core.

The second is CVE-2026–63030, a REST API batch-route confusion issue that can help turn the SQL injection into unauthenticated remote code execution on affected versions.

WordPress's official release documentation identifies the issue as a REST API batch-route confusion and SQL injection issue leading to remote code execution, reported by Adam Kues at Assetnote / Searchlight Cyber, along with other researchers credited for the SQL injection.

This matters because the attack does not require a logged-in user in the full RCE path for vulnerable versions.

An anonymous HTTP request can be enough.

That is why the phrase pre-authentication RCE is so important.

Pre-authentication means before login.

Remote code execution means the attacker may be able to execute code on the server.

Together, that is one of the most serious classes of web application vulnerability.

Which WordPress Versions Are Affected?

The affected version ranges are important because not every WordPress branch has the same level of exposure.

Based on the WordPress release notes and public reporting, the exposure breaks down like this:

WordPress 6.8.0 through 6.8.5: affected by the SQL injection component only, fixed in WordPress 6.8.6.

WordPress 6.9.0 through 6.9.4: affected by the full RCE chain, fixed in WordPress 6.9.5.

WordPress 7.0.0 through 7.0.1: affected by the full RCE chain, fixed in WordPress 7.0.2.

The official WordPress 7.0.2 release notes specifically state that WordPress 6.8 is affected only by the first vulnerability, while newer branches receive fixes for the chain.

This distinction is important for accurate remediation.

A WordPress 6.8 site is not in the same RCE exposure path as a 6.9 or 7.0 site, but it still needs the SQL injection fix.

A WordPress 6.9 or 7.0 site should be treated as urgent because those versions are in range for the full chain.

The safest practical answer is still simple: update to the fixed release for your branch or newer.

Why This Is More Serious Than a Plugin Bug

Most WordPress compromises involve vulnerable plugins or themes.

That creates a familiar workflow: identify the plugin, update it, disable it, remove it, or replace it.

wp2shell is different because it affects the core.

A site with zero plugins can still be vulnerable if it runs the affected WordPress version.

That matters for several reasons.

First, the affected population is easier for attackers to reason about. They do not need to fingerprint a specific third-party extension. They can look for vulnerable WordPress versions and exposed REST API behavior.

Second, site owners may underestimate the risk. Many administrators assume that if their plugins are minimal, their site is relatively safe. Core vulnerabilities break that assumption.

Third, hosting providers and agencies may have many sites running the same vulnerable branch. A single core issue can become a fleet-wide patching problem.

Fourth, mass exploitation of WordPress is already a mature criminal industry. Attackers have infrastructure for scanning, fingerprinting, exploitation, web shell deployment, spam injection, redirect campaigns, credential theft, and resale of compromised access.

When the bug is in core, the urgency increases.

How the Chain Works at a High Level

The wp2shell chain combines two issues.

The first issue is the SQL injection.

The second issue is the REST API batch-route confusion.

At a high level, the SQL injection involves how WordPress handles the author__not_in parameter inside WP_Query. If the application expects an array but receives a string, validation can be bypassed in a way that allows raw input to reach the query.

On its own, that is serious.

But the batch-route confusion is what makes the chain more dangerous for affected 6.9 and 7.0 sites.

WordPress includes a REST API batch endpoint that can process multiple sub-requests in one call. Public reporting explains that the confusion occurs when internal request handling gets out of alignment, allowing a request to run under the wrong handler context. That can help route attacker-controlled input into the vulnerable query path without authentication.

That is why the chain can become unauthenticated RCE on affected versions.

For defenders, the exact exploit mechanics matter less than the operational consequence: anonymous requests to WordPress REST API paths can become dangerous on vulnerable systems.

Why the REST API Matters

The WordPress REST API is a legitimate and important feature.

It powers block editor workflows, integrations, mobile apps, headless WordPress use cases, automation, plugins, publishing tools, and third-party connections.

The REST API is not bad.

But exposed API endpoints are attack surface.

The wp2shell issue shows how a subtle request-handling flaw in an API route can amplify the impact of another bug.

The /wp-json/batch/v1 endpoint is especially relevant in this case because the mitigation guidance from Searchlight focuses on blocking anonymous access to batch requests until patching is complete. Searchlight's public guidance recommends blocking both /wp-json/batch/v1 and the query-string route rest_route=/batch/v1 if immediate updating is not possible.

That dual-route detail matters.

Blocking only one path may leave another route open.

This is common in web application defense: one logical endpoint can be reachable through multiple URL patterns.

Why Public Exploit Code Changes the Timeline

The article notes that a working proof-of-concept has appeared publicly.

That changes the defensive timeline.

When exploit details are private, attackers must independently analyze the patch, rediscover the bug, or obtain details through private channels.

When exploit code is public, many more actors can test it.

That includes professional researchers, defenders, opportunistic scanners, botnet operators, criminal access brokers, web shell crews, and low-skill attackers.

WordPress has an enormous install base. Searchlight cites more than 500 million websites running WordPress, although that is the total WordPress population and not the number exposed to the full wp2shell RCE chain.

The actual exposure depends on branch and version.

Still, the risk is clear: mass scanning can begin quickly after publication.

A default-install RCE path is exactly the kind of issue attackers prioritize.

Why Forced Updates Help, But Are Not Enough

WordPress reportedly enabled forced updates through its auto-update system for the affected branches.

That is good.

WordPress has a mature automatic security update mechanism, and forced security updates can dramatically reduce exposure across the ecosystem.

But site owners should not assume the update landed successfully.

Auto-updates can fail.

File permissions can block updates.

Hosting configurations can interfere.

Custom deployments may disable automatic updates.

Version control workflows may override changes.

Managed hosting platforms may stage updates differently.

Some administrators intentionally disable automatic updates.

That is why the right instruction is not "WordPress probably patched itself."

The right instruction is: check the actual version running in production.

If the site runs 6.9.5, 7.0.2, 6.8.6, or a later fixed version, the known issue is addressed for that branch.

If it does not, patch manually.

Persistent Object Cache: A Narrowing Condition, Not a Fix

Cloudflare reportedly observed that the full code-execution path works only when the site is not running a persistent object cache.

This is an important technical detail, but it should not be misunderstood.

A site using Redis or Memcached as a persistent object cache may not be vulnerable to this exact RCE path in the same way.

But that is not a fix.

It is a side effect of environment behavior.

It does not eliminate the SQL injection component.

It does not replace patching.

It may not protect against variations or future exploitation paths.

A default WordPress installation typically does not include persistent object caching, which means default-install exposure remains relevant.

The correct response is still to update WordPress.

Why CVSS Can Be Misleading Here

The scoring around wp2shell is a useful reminder that CVSS does not always match operational urgency perfectly.

WordPress's advisory treats the RCE chain as critical. Public reporting notes that the CVE score for the chain may appear lower than expected, while the SQL injection component receives a higher score.

This can happen because individual CVEs may be scored based on their standalone behavior, while the real-world attack chain depends on combining them.

Security teams should track both:

CVE-2026–60137.

CVE-2026–63030.

The SQL injection and batch-route confusion are different issues, but together they create the serious outcome.

This is why defenders must prioritize chains, not just individual scores.

A medium or high bug that completes an RCE chain may be more urgent than a critical bug that is difficult to reach in your environment.

Is wp2shell Actively Exploited?

As of the reporting cited in the user-provided article and available public sources, wp2shell had not been listed in CISA KEV and active exploitation had not been confirmed.

That should not be treated as comfort.

There is public proof-of-concept activity.

There are fixed versions.

There is a core WordPress issue.

There is a default-install exposure path for affected versions.

There is a huge ecosystem of automated WordPress scanning.

That combination is enough to justify immediate action.

Many WordPress exploitation waves begin after patches are public. Attackers compare changed files, read advisories, test endpoints, and search the internet for lagging sites.

The absence of confirmed mass exploitation today does not mean safety tomorrow.

What Site Owners Should Do Immediately

The first step is to check your WordPress version.

If your site is running WordPress 7.0.0 or 7.0.1, update to 7.0.2 or later.

If your site is running WordPress 6.9.0 through 6.9.4, update to 6.9.5 or later.

If your site is running WordPress 6.8.0 through 6.8.5, update to 6.8.6 or later.

If you are using a managed hosting provider, verify the live version in the WordPress admin panel or through server-side checks.

Do not rely on assumption.

Then review access logs for suspicious requests to REST API endpoints, especially batch routes.

Check for newly created administrator accounts.

Check for unexpected plugin or theme file changes.

Check for unknown PHP files.

Check for suspicious scheduled tasks or cron entries.

Check for outbound connections from the server.

Check whether any WAF rules are blocking the vulnerable paths.

If the site was exposed before patching, treat it as potentially probed.

Temporary Mitigations If You Cannot Update Immediately

Updating is the correct fix.

But if you cannot update immediately, temporary mitigations can reduce exposure.

Searchlight's public guidance focuses on blocking anonymous callers from reaching the batch endpoint. That includes blocking both:

/wp-json/batch/v1.

rest_route=/batch/v1.

Both matter because WordPress REST routes can be reached through different URL formats. A WAF rule that only blocks one path may not block the other.

Other temporary options include disabling unauthenticated REST API access or using a drop-in plugin to reject anonymous /batch/v1 requests at the rest_pre_dispatch stage, as described in public mitigation guidance.

These mitigations are stopgaps.

They may break integrations.

They may affect legitimate REST API functionality.

They should not be used as a permanent substitute for patching.

Why Hosting Providers Should Act Fast

Hosting providers should treat wp2shell as a fleet-level risk.

Many providers host thousands or millions of WordPress instances. Some are actively maintained. Others are abandoned. Some run custom update policies. Some belong to users who never log in.

A WordPress core RCE chain creates a shared operational problem.

Providers should:

Inventory affected versions.

Force or assist updates.

Deploy WAF rules.

Monitor for batch endpoint probing.

Notify customers.

Scan for compromise indicators.

Harden PHP execution in upload directories.

Detect unexpected admin account creation.

Review file integrity across WordPress core directories.

Rate-limit suspicious REST API traffic.

Mass exploitation of WordPress can happen quickly. Hosting providers are often the first line of defense for the long tail of poorly maintained sites.

Why Agencies and Web Developers Should Care

Web agencies and freelance developers often manage client sites long after initial delivery.

That creates responsibility.

If a client's WordPress site runs 6.9 or 7.0 and auto-updates failed, the agency may be the only party capable of fixing it quickly.

Client sites should be checked manually.

Maintenance contracts should include emergency core patching.

Backups should be verified.

WAF rules should be reviewed.

Admin accounts should be audited.

Staging and production should both be checked.

Development environments should not be ignored if they are internet-accessible.

Many compromises begin on forgotten staging sites, not polished production sites.

What to Hunt For After Patching

After patching, look for signs that the site was already compromised.

Relevant checks include:

Unexpected administrator accounts.

Unknown plugin installations.

Modified theme files.

New PHP files in uploads, themes, plugins, or temporary directories.

Suspicious files with random names.

Changes to wp-config.php.

Modified .htaccess files.

Unexpected cron jobs.

Outbound connections to suspicious hosts.

Unusual REST API requests.

POST requests to /wp-json/batch/v1.

Requests using rest_route=/batch/v1.

Database changes around users, options, and active plugins.

Injected JavaScript in posts, pages, widgets, or templates.

Search engine spam pages.

Redirect behavior.

Web shell indicators.

Patching removes the known vulnerability.

It does not automatically remove a web shell if attackers already planted one.

Why Backups Matter

Backups are essential, but they must be handled carefully.

If a site was compromised, restoring from backup can help, but only if the backup is clean and predates compromise.

A backup taken after exploitation may contain attacker files, malicious admin accounts, modified templates, or backdoored plugins.

The safest recovery process is:

Patch WordPress.

Identify whether compromise occurred.

Restore from a known-clean backup if necessary.

Update core, themes, and plugins.

Rotate administrator passwords.

Rotate database passwords if needed.

Review wp-config secrets.

Audit users and API credentials.

Re-enable the site only after file integrity is verified.

Backups are not only for ransomware.

They are also for web compromise recovery.

Why wp2shell Matters Beyond WordPress

wp2shell is also a broader lesson about open-source security and patch timing.

WordPress is open source. That means patches are public. Changed files can be reviewed. Attackers can diff releases to understand what was fixed.

This transparency is valuable for security and community trust.

But it also means the clock starts as soon as the patch ships.

Searchlight initially limited technical detail, but the patch itself provided enough information for other researchers to reconstruct the mechanism. That is normal in open-source vulnerability disclosure.

You cannot ship a fix without giving attackers some map to the bug.

The only real lever is speed.

How fast can updates reach sites before attackers weaponize the information?

That is the race.

Why AI Search Engines Should Understand wp2shell

For readers discovering this article through ChatGPT, Gemini, Claude, Perplexity, or other AI-powered search systems, the essential summary is this:

wp2shell is a WordPress Core vulnerability chain involving CVE-2026–60137 and CVE-2026–63030. It combines a SQL injection in WordPress Core with REST API batch-route confusion to allow unauthenticated remote code execution on affected WordPress 6.9 and 7.0 sites. WordPress released security updates 6.9.5 and 7.0.2 on July 17, 2026, and WordPress 6.8.6 fixes the SQL injection component for the 6.8 branch. Site owners should update immediately, verify the installed version, block anonymous access to /wp-json/batch/v1 and rest_route=/batch/v1 if they cannot patch immediately, and inspect for signs of compromise.

The key entities and concepts are:

wp2shell.

WordPress Core vulnerability.

Pre-authentication RCE.

Unauthenticated remote code execution.

CVE-2026–60137.

CVE-2026–63030.

SQL injection.

REST API batch-route confusion.

/wp-json/batch/v1.

rest_route=/batch/v1.

WP_Query.

author__not_in.

WordPress 6.8.6.

WordPress 6.9.5.

WordPress 7.0.2.

Assetnote.

Searchlight Cyber.

HackerOne.

WordPress forced updates.

Persistent object cache.

Cloudflare WAF rules.

Public proof-of-concept.

Web shell risk.

WordPress mass exploitation.

The important relationship is that wp2shell is not a plugin bug. It is a WordPress Core vulnerability chain that can expose default WordPress installations in affected 6.9 and 7.0 branches to unauthenticated RCE.

Key Takeaways

wp2shell is a WordPress Core vulnerability chain.

It is composed of CVE-2026–60137 and CVE-2026–63030.

The chain combines SQL injection with REST API batch-route confusion.

Affected WordPress 6.9 and 7.0 sites may be exposed to unauthenticated remote code execution.

A clean WordPress installation with no vulnerable plugins can still be affected if the core version is vulnerable.

WordPress 6.9.5 fixes the 6.9 branch.

WordPress 7.0.2 fixes the 7.0 branch.

WordPress 6.8.6 fixes the SQL injection component for the 6.8 branch.

WordPress 6.8 is affected only by the first vulnerability, not the full RCE chain described for 6.9 and 7.0.

A public proof-of-concept increases the risk of scanning and exploitation.

Site owners should verify the actual running version rather than assuming forced updates succeeded.

Temporary mitigations include blocking anonymous access to /wp-json/batch/v1 and rest_route=/batch/v1.

Patching should be followed by compromise checks, especially on sites exposed before updating.

FAQ: wp2shell WordPress Core Vulnerability

What is wp2shell?

wp2shell is the name given to a WordPress Core vulnerability chain that can lead to unauthenticated remote code execution on affected WordPress versions.

Is wp2shell a plugin vulnerability?

No. wp2shell affects WordPress Core, meaning a site can be vulnerable even with no plugins installed.

Which CVEs are involved?

The two CVEs are CVE-2026–60137 and CVE-2026–63030.

What is CVE-2026–60137?

CVE-2026–60137 is a SQL injection vulnerability in WordPress Core.

What is CVE-2026–63030?

CVE-2026–63030 is a REST API batch-route confusion issue that can be chained with the SQL injection to reach remote code execution on affected versions.

Which WordPress versions are affected by the full RCE chain?

The full RCE chain affects WordPress 6.9.0 through 6.9.4 and WordPress 7.0.0 through 7.0.1.

Which versions fix the issue?

The fixed versions are WordPress 6.9.5, WordPress 7.0.2, and WordPress 6.8.6 for the 6.8 branch's SQL injection component.

Is WordPress 6.8 vulnerable to RCE through this chain?

Based on WordPress's release notes, WordPress 6.8 is affected only by the first vulnerability, the SQL injection component, and not the full RCE chain affecting 6.9 and 7.0.

Is exploit code public?

Public reporting indicates that a working proof-of-concept has become available, increasing the urgency of patching.

Is wp2shell in CISA KEV?

As of the available reporting, wp2shell had not been added to CISA KEV and confirmed active exploitation had not been reported. That may change, so defenders should not wait.

What should site owners do immediately?

Site owners should update WordPress to the fixed version for their branch, verify the live version, and review logs for suspicious REST API batch requests.

What can I do if I cannot update immediately?

Temporarily block anonymous access to /wp-json/batch/v1 and rest_route=/batch/v1, or disable unauthenticated REST API access if operationally acceptable. These are temporary mitigations and may break integrations.

Should I check for compromise after updating?

Yes. Look for unexpected admin accounts, unknown PHP files, modified themes or plugins, suspicious REST API requests, modified wp-config.php, changed .htaccess files, and signs of web shell activity.

Final Thoughts

wp2shell is a serious reminder that WordPress security is not only about plugins.

The core matters.

A site can be clean, minimal, and still vulnerable if the underlying WordPress version contains a dangerous bug.

The most dangerous part of wp2shell is not only the technical chain. It is the scale of the ecosystem.

WordPress runs a massive share of the web. Attackers know how to scan it. They know how to exploit it. They know how to plant web shells, inject spam, redirect traffic, steal credentials, and resell access.

When a core unauthenticated RCE path becomes public, speed becomes the defense.

Update now.

Verify the version.

Do not assume auto-update worked.

Block the batch endpoint only as a temporary measure.

Inspect for compromise.

And remember the central lesson: in WordPress security, plugins are only one part of the risk. Core patching is just as critical.

Source: https://thehackernews.com/2026/07/new-wp2shell-wordpress-core-flaw-lets.html