What happens when a feature built to connect WordPress with other applications becomes an attacker’s entry point?
The WordPress REST API lets applications communicate with WordPress, access site data, and build integrations. This flexibility also makes it an important security boundary.
CVE-2026-63030 and CVE-2026-60137 form the wp2shell attack chain, allowing unauthenticated attackers to move from REST API abuse to SQL injection and remote code execution.
So, what exactly happens, and what should organizations be watching for?
Why the WordPress REST API Matters
Before looking at the attack chain, it is important to understand the importance of the WordPress REST API.
The REST API’s HTTP endpoints allow applications to communicate with WordPress. Developers can communicate with users, posts, settings, and other WordPress features through these APIs.
This makes the API useful for:
-
Headless WordPress applications -
Mobile and web applications -
Third-party integrations -
Automated workflows -
Custom WordPress functionality
Security rules around authorization and authentication are essential since these endpoints can be accessed via HTTP requests.
The impact can go beyond the API itself if an attacker is able to access features that ought to require authorization.
CVE-2026-63030 becomes significant in this situation.
The First Weakness: CVE-2026-63030
CVE-2026-63030 is a critical WordPress vulnerability affecting the REST API batch endpoint.
The issue is a route confusion flaw in the REST API batch endpoint. Attackers can exploit it to bypass authentication and access internal handlers without the required permission checks.
The WordPress REST API can be the entry point. A crafted batch request can bypass authentication and access internal functions.
The Second Weakness: CVE-2026-60137
CVE-2026-60137 affects the author__not_in parameter in WP_Query. Poor input sanitization can allow SQL injection.
Instead of treating the supplied value as expected input, the vulnerable query handling can allow crafted input to alter the resulting database query.
This creates a path for SQL injection.
WordPress versions 6.8 and later are impacted by the vulnerability, which includes:
| WordPress branch | Vulnerable versions | Fixed version |
|---|---|---|
| 6.8.x | Before 6.8.6 | 6.8.6 |
| 6.9.x | Before 6.9.5 | 6.9.5 |
| 7.0.x | Before 7.0.2 | 7.0.2 |
The SQL injection flaw is significant by itself because database information may be exposed or manipulated.
However, when combined with the REST API weakness, it becomes part of a much more serious attack path.
How the wp2shell Chain Comes Together
The two vulnerabilities become more dangerous when chained together.
-
Step 1: Reach the WordPress REST API
The attacker sends a crafted request to the REST API batch endpoint on a vulnerable WordPress site. -
Step 2: Bypass the expected authorization
CVE-2026-63030 lets attackers bypass permission checks to access internal functions. -
Step 3: Reach vulnerable query functionality
The attack can then make use of functionality affected by CVE-2026-60137. -
Step 4: Trigger SQL injection
Malicious input targeting the vulnerable author__not_in parameter can alter a database query. -
Step 5: Move toward remote code execution
Chaining both vulnerabilities can enable unauthenticated RCE through wp2shell on WordPress 6.9+, making the combined risk more serious.
What Attackers Can Do After Exploitation
The risk does not necessarily end when the initial vulnerability is exploited.
Security researchers have observed several forms of post-exploitation activity associated with wp2shell attacks.
These include:
-
Creating unauthorized administrator accounts -
Enumerating users and collecting administrator usernames and email addresses -
Uploading malicious WordPress plugins -
Accessing the WordPress administration panel -
Uploading PHP web shells -
Attempting to obtain database credentials and authentication keys -
Deploying additional malicious tools
A vulnerable WordPress site may be found automatically rather than through a targeted attack. This means attackers do not need to target an organization directly. Public exploit code can make vulnerable systems easier to find at scale.
What Should Security Teams Look For?
Patching is the most important step, but organizations should also investigate whether vulnerable systems were already targeted.
Security teams should check for signs such as:
-
Unexpected administrator accounts
Look for administrator accounts that were not created by authorized users or administrators.
Researchers have reported more than 100 backdoor administrator accounts associated with exploitation activity. -
Malicious plugins
Unexpected plugins deserve particular attention, especially plugins that appeared recently or were not approved by the organization.
Attackers have used malicious plugins as a way to maintain access and execute code. -
Suspicious PHP files
Web shells and other unexpected PHP files in the WordPress installation can indicate post-exploitation activity. -
Unusual REST API requests
Pay particular attention to unexpected requests involving the WordPress REST API batch endpoint.
A request by itself does not prove compromise, but unusual activity combined with other indicators should trigger further investigation. -
Database anomalies
Security teams should also examine WordPress database activity for unexpected changes associated with exploitation.
The goal is not simply to determine whether the server is patched. It is to establish whether an attacker gained access before the patch was applied.
How Fidelis Elevate® Helps Detect the Attack
Patching is essential, but teams also need visibility into suspicious activity. Fidelis Elevate® correlates threats across network, endpoint, and cloud environments.
This visibility helps security teams investigate suspicious activity across the attack surface, including activity related to WordPress attacks.
Fidelis Elevate® helps teams:
-
Correlate network, endpoint, and cloud threat data for greater context. -
Map the cyber terrain to improve visibility and risk awareness. -
Automate detection and response workflows. -
Investigate suspicious activity across the environment. -
Reduce manual effort and accelerate threat response.
For attacks involving the WordPress REST API, this unified approach can help security teams move beyond a single suspicious request and investigate related activity across their environment.
-
Detect post-exploitation activity with broader security visibility -
Gain unified visibility across network, endpoint, and cloud environments -
Accelerate threat detection and response with integrated XDR capabilities
The Bigger Lesson for WordPress REST API Security
The wp2shell attack chain highlights an important security lesson: vulnerabilities do not always operate independently.
A REST API authorization weakness can provide access to functionality that an attacker should not reach. A separate SQL injection flaw can then provide another capability. Chained vulnerabilities can have a much greater impact, especially on public-facing WordPress sites.
What Organizations Should Do Now
Organizations running WordPress should treat the wp2shell vulnerabilities as an active security concern.
The immediate priorities are straightforward:
-
Update WordPress to a fixed version. -
Verify that the update was successfully applied. -
Review vulnerable installations for signs of exploitation. -
Check for unauthorized administrator accounts. -
Inspect plugins and files for malicious changes. -
Review relevant logs and database activity. -
Continue monitoring the WordPress REST API and surrounding infrastructure.
The main takeaway is simple: WordPress REST API security goes beyond protecting individual endpoints. Organizations also need to understand how vulnerabilities can be chained to create larger attack paths.
CVE-2026-63030 and CVE-2026-60137 show how two separate vulnerabilities can be chained into a serious attack. For organizations running public-facing WordPress sites, timely patching and post-patch investigation are essential to reducing risk.
The post WordPress REST API Security: What the wp2shell Attack Chain Teaches Us appeared first on Fidelis Security.
