A serious WordPress security issue known as wp2shell has revealed how a single anonymous web request could potentially lead to remote code execution on vulnerable websites. Unlike many WordPress attacks that depend on an outdated plugin or theme, this weakness exists inside WordPress core itself, meaning even a clean installation with no third-party extensions could be affected.
The attack combines two separate vulnerabilities. One allows specially crafted input to reach a vulnerable database query, while the other abuses WordPress's REST API batch-processing system to bypass normal access restrictions. When chained together, the flaws can allow an attacker without an account to progress from a public HTTP request to running code on the underlying website.
WordPress has released security updates for affected branches, but with technical details and working exploit code now publicly available, website owners should verify their installed version immediately rather than assume an automatic update has already been applied.
Two Vulnerabilities Combined Into One Dangerous Attack
wp2shell is not a single programming mistake. It is an attack chain built from two independently tracked vulnerabilities:
The SQL injection flaw provides a way to manipulate a database query. On its own, however, its impact is more limited because an attacker still needs a way to reach the vulnerable parameter under the right conditions.
The REST API flaw supplies that missing path. By confusing how WordPress associates multiple requests with their handlers, an attacker may be able to route malicious input into functionality that should not be anonymously accessible.
Together, the two weaknesses create the full unauthenticated code-execution chain.
Bare WordPress Installations Are Still at Risk
One of the most important details is that the problem does not require a vulnerable plugin.
WordPress attacks are often blamed on abandoned themes, outdated page builders or poorly maintained extensions. That assumption can lead administrators to believe that a minimal website running only core WordPress is automatically safer.
In this case, the vulnerable components are part of WordPress itself. A default installation running an affected version may therefore remain exposed even when every plugin has been removed.
That makes the issue particularly significant for organisations that rely on simplified or tightly controlled WordPress deployments and assume their limited plugin footprint protects them from most serious vulnerabilities.
Which WordPress Versions Are Affected?
The two vulnerabilities affect different release ranges, so not every vulnerable installation faces the same level of risk.
WordPress 6.8.0 through 6.8.5
These versions are affected by the SQL injection vulnerability but not the full unauthenticated remote-code-execution chain. The issue is corrected in WordPress 6.8.6.
WordPress 6.9.0 through 6.9.4
These versions contain both vulnerabilities and are exposed to the complete wp2shell attack chain. The fix is included in WordPress 6.9.5.
WordPress 7.0.0 through 7.0.1
These releases are also exposed to the full attack chain. Administrators should upgrade to WordPress 7.0.2.
The reported WordPress 7.1 beta release also includes both corrections.
The distinction matters because a WordPress 6.8 site may still be vulnerable to database manipulation, but it is not exposed to remote code execution through this particular chain.
How the SQL Injection Works
The database-related weakness involves the author__not_in parameter used by WordPress's WP_Query system.
This parameter is expected to receive an array of author IDs that should be excluded from a query. The vulnerable logic reportedly handles the value differently when an attacker supplies a string instead of the expected array.
Because the input is no longer processed through the anticipated array-handling path, a malicious value may reach the database query without the required protection.
This creates the SQL injection condition represented by CVE-2026-60137.
SQL injection can be extremely serious because it may allow an attacker to interfere with database queries, retrieve information or alter how WordPress processes stored content. However, the full wp2shell attack requires another vulnerability to deliver this malicious input anonymously.
The REST API Batch Route Opens the Door
WordPress includes a batch REST API endpoint that allows several subrequests to be processed within a single call.
This functionality is available through the /wp-json/batch/v1 route and can also be reached through WordPress's query-string-based REST routing mechanism.
Internally, WordPress reportedly tracks the individual requests and their corresponding handlers using parallel arrays. Under certain error conditions, those arrays can become misaligned.
When that happens, one subrequest may be processed using the handler intended for another request.
By carefully nesting and arranging requests, an attacker can exploit this mismatch to bypass the batch endpoint's normal allow-list and send input to functionality that should not be reachable anonymously.
That input can then be directed into the vulnerable WP_Query parameter, completing the path from a public request to the SQL injection and ultimately to code execution.
Why the Attack Is Considered Critical
The full chain reportedly requires no authentication and no special configuration beyond running a vulnerable WordPress version without a persistent object cache.
An attacker does not need:
Instead, the attack can begin with a specially crafted HTTP request sent to a public WordPress website.
This significantly lowers the barrier to exploitation and makes automated scanning practical. Once exploit code becomes publicly available, attackers can build tools that search the internet for vulnerable sites and test them at scale.
Public Exploit Code Changes the Risk
The patches are already available, but so are the technical details needed to understand the vulnerabilities.
Researchers have published explanations of the attack mechanism, and a working proof-of-concept has reportedly appeared on GitHub. That means the issue is no longer theoretical or limited to the researchers who originally discovered it.
Public exploit code does not automatically mean widespread attacks are already taking place. However, it makes experimentation, automation and weaponisation much easier.
The time between public disclosure and mass scanning can be very short for WordPress vulnerabilities because attackers already have infrastructure designed to identify sites by version, probe exposed endpoints and install malicious payloads.
Website owners should therefore treat patching as an immediate priority rather than waiting for confirmed exploitation reports.
Automatic Updates May Not Be Enough
WordPress reportedly enabled forced security updates for vulnerable 6.9 and 7.0 installations.
However, administrators should not assume the update succeeded simply because WordPress supports automatic patching.
Updates can fail for many reasons, including:
It is also unclear whether every website that explicitly disabled automatic updates will still receive the forced release.
The safest approach is to log in to the WordPress administration dashboard or inspect the installed files directly and confirm the exact version currently running.
Persistent Object Caching May Interrupt the RCE Chain
The remote-code-execution path reportedly works only when the affected website is not using a persistent object cache.
Sites using technologies such as Redis or Memcached for persistent WordPress object caching may not be exploitable through this exact code-execution method.
However, this should not be treated as a security fix.
Persistent caching may disrupt one stage of the chain, but it does not remove the underlying SQL injection vulnerability. Configuration changes, caching failures or differences between environments could also affect whether the protection remains effective.
Most default WordPress installations do not include persistent object caching, so ordinary installations remain within the reported exposure conditions.
Security Scores Do Not Tell the Whole Story
The vulnerability ratings may appear confusing.
The REST API batch-route flaw has reportedly received a lower severity score than the SQL injection issue, even though it is the component that makes the complete unauthenticated code-execution chain possible.
This happens because vulnerability scores usually assess each CVE independently.
Viewed alone, the route confusion may look like a request-parsing or access-control problem. The SQL injection receives a higher score because it directly affects the database.
When the two are combined, however, their practical impact becomes much greater than either vulnerability might suggest individually.
Security teams should therefore track both CVEs and evaluate the complete attack chain instead of relying only on the numerical score attached to one record.
What Website Owners Should Do Now
The most important action is to update WordPress immediately.
Affected installations should move to one of the following secured versions:
Before updating, administrators should take a reliable backup of the website files and database. The update should then be completed as quickly as possible, with functionality checked afterwards.
Security teams should also review web server, firewall and application logs for suspicious requests involving:
/wp-json/batch/v1 rest_route=/batch/v1 Finding unusual activity does not automatically confirm exploitation, but it may justify a deeper investigation.
Temporary Protection When Immediate Updating Is Impossible
Organisations that cannot update immediately can temporarily restrict anonymous access to the vulnerable batch endpoint.
At a Web Application Firewall, both route formats should be blocked:
/wp-json/batch/v1 rest_route=/batch/v1Blocking only the first path is insufficient because attackers may use the query-string route instead.
Some managed WAF providers have already introduced detection and blocking rules for the attack chain. Administrators should verify that the relevant managed rules are enabled and operating in blocking mode rather than monitoring only.
Another option is to disable unauthenticated REST API access. However, this can disrupt mobile applications, integrations, headless WordPress deployments and other legitimate services.
A temporary plugin that rejects anonymous batch requests can also reduce exposure, but adding new code to avoid patching vulnerable core files should only be considered a short-term measure.
None of these workarounds should replace the official update.
Why WordPress Vulnerabilities Spread So Quickly
WordPress powers an enormous portion of the public web, making serious core vulnerabilities especially attractive to cybercriminals.
Attackers do not need to identify each website manually. Automated scanners can search millions of domains, detect WordPress installations and test exposed endpoints within hours.
Once a vulnerable site is compromised, it may be used to:
Older incidents have shown that even plugin vulnerabilities affecting non-default configurations can lead to thousands of compromised websites. A core vulnerability that works on ordinary installations creates a potentially broader opportunity.
Patching Reveals the Vulnerability by Design
Open-source security fixes create an unavoidable challenge.
When WordPress publishes an update, anyone can compare the modified files against the previous version. Those differences can reveal which functions changed and provide clues about the original vulnerability.
Researchers and attackers can then reverse-engineer the patch, reconstruct the vulnerable behaviour and develop proof-of-concept exploits.
This does not mean security fixes should remain secret. Delaying the patch would leave every administrator unprotected. The practical defence is to distribute the update faster than attackers can analyse and weaponise it.
That is why forced updates and rapid patch adoption matter so much in situations like wp2shell.
Final Thoughts
wp2shell is a reminder that a WordPress website does not need a vulnerable plugin to face a critical security problem.
By chaining a REST API batch-processing flaw with a core SQL injection vulnerability, attackers may be able to turn an anonymous HTTP request into remote code execution on affected WordPress 6.9 and 7.0 installations.
The fixes are available, but the exploit mechanism is now public. That shifts the situation from responsible disclosure into a race between website owners applying updates and attackers scanning for systems that remain exposed.
Administrators should verify their WordPress version, apply the appropriate security release and inspect logs for suspicious batch endpoint activity. Temporary WAF restrictions can reduce exposure, but updating WordPress core remains the only reliable long-term solution.
Comments