By Ryan Dewhurst —

Critical WordPress wp2shell Vulnerability Allows Unauthenticated Remote Code Execution

Critical WordPress wp2shell Vulnerability Allows Unauthenticated Remote Code Execution

Two critical vulnerabilities in WordPress Core, tracked as CVE-2026-63030 and CVE-2026-60137, can be chained to achieve unauthenticated remote code execution.

The vulnerability chain, publicly referred to as wp2shell, affects WordPress Core rather than a third-party plugin. An attacker does not require a valid WordPress account, administrator privileges or user interaction to target a vulnerable installation.

Successful exploitation could allow an attacker to execute code on the underlying WordPress server, potentially resulting in complete compromise of the affected website.

KEVIntel recommends that organisations and website administrators update affected WordPress installations immediately.

WordPress wp2shell vulnerability summary

  • Product: WordPress Core
  • Vulnerability type: SQL injection and REST API route confusion
  • Potential impact: Remote code execution
  • Authentication required: No
  • User interaction required: No
  • Public name: wp2shell
  • Exploitation status: Not confirmed in the wild at the time of publication
  • Recommended action: Update affected WordPress sites immediately

What is the WordPress wp2shell vulnerability?

The wp2shell vulnerability is an attack chain involving weaknesses in WordPress Core.

According to the public disclosure, an attacker can combine a SQL injection vulnerability with unexpected behaviour in the WordPress REST API batch route.

When successfully chained, the vulnerabilities can lead to unauthenticated remote code execution.

Remote code execution is one of the most serious vulnerability outcomes because it can allow an attacker to run commands or code on the underlying server.

Depending on the WordPress hosting environment and the permissions available to the web server process, successful exploitation could potentially allow an attacker to:

  • Modify WordPress files
  • Upload web shells or backdoors
  • Create malicious administrator accounts
  • Access database contents
  • Steal configuration files or credentials
  • Redirect visitors
  • Inject malicious JavaScript
  • Establish persistent access
  • Use the server for further attacks

The precise impact will depend on the server configuration and the privileges assigned to the WordPress and web server processes.

Which WordPress versions are affected?

The wp2shell remote code execution chain reportedly affects:

  • WordPress 6.9.0 through 6.9.4
  • WordPress 7.0.0 through 7.0.1
  • WordPress 7.1 beta 1

The vulnerability is fixed in:

  • WordPress 6.9.5
  • WordPress 7.0.2
  • WordPress 7.1 beta 2

WordPress administrators should update to the latest available supported release for their installation branch.

WordPress 6.8 installations should also be updated to WordPress 6.8.6 to address a related SQL injection vulnerability, although that branch is not reportedly affected by the complete wp2shell remote code execution chain.

Update WordPress immediately

Affected WordPress sites should be updated immediately.

WordPress will deploy security updates automatically to supported installations, but site owners should verify that the update completed successfully.

Automatic updates can fail because of:

  • Incorrect filesystem permissions
  • Disabled background updates
  • Hosting-provider restrictions
  • Custom deployment processes
  • Incompatible plugins or themes
  • Insufficient disk space
  • Version-control restrictions
  • Failed maintenance tasks

Check the installed WordPress version directly from the administration dashboard, hosting control panel, command line or asset-management tooling.

KEVIntel independently reproduced the vulnerability

KEVIntel independently investigated the wp2shell vulnerability immediately following its public disclosure.

In a controlled environment, KEVIntel was able to reproduce the vulnerability and create a working proof of concept.

This validation indicates that the vulnerability is trivially and practically exploitable, and should not be dismissed as a theoretical security issue.

KEVIntel is not publishing the proof of concept, exploitation payloads or detailed reproduction instructions publicly while a significant number of WordPress installations may remain unpatched.

Independent reproduction does not mean exploitation has been observed in the wild. It confirms technical exploitability, while active exploitation requires separate evidence from real-world attacks, telemetry or credible reporting.

Has the WordPress wp2shell vulnerability been exploited?

KEVIntel has not confirmed exploitation in the wild at the time of publication.

There is an important distinction between:

  • A vulnerability being disclosed
  • A vulnerability being technically exploitable
  • A working proof of concept existing privately
  • Public exploit code becoming available
  • Attackers scanning for vulnerable sites
  • Exploitation attempts being observed
  • Successful compromise being confirmed

The wp2shell vulnerability has reached the technical-validation stage, but KEVIntel has not yet obtained sufficient evidence to classify it as actively exploited.

That status will change quickly.

Why exploitation attempts are likely

The wp2shell vulnerability has several characteristics that make it attractive to attackers:

  • It affects WordPress Core
  • It does not require authentication
  • It does not require user interaction
  • It can potentially lead to remote code execution
  • WordPress has a very large internet-facing attack surface
  • Vulnerable versions may be easy to identify
  • A practical exploit can be developed
  • Unpatched WordPress sites are commonly targeted by automated botnets

WordPress vulnerabilities are frequently incorporated into automated scanners and exploitation frameworks after technical details become available.

Attackers may also independently reverse engineer the security update to determine what changed and develop their own exploit.

For these reasons, administrators should treat the period immediately after disclosure as high risk.

Temporary mitigation for wp2shell

Updating WordPress is the preferred remediation.

Where an immediate update is not possible, administrators can consider temporarily restricting unauthenticated access to the WordPress REST batch API.

Defensive controls should account for both common request formats:

/wp-json/batch/v1

and:

rest_route=/batch/v1

Blocking only one request format may leave the alternative route accessible.

Organisations may implement temporary restrictions using:

  • A web application firewall
  • A reverse proxy
  • Web server access controls
  • WordPress security middleware
  • Hosting-provider security controls

These mitigations may interfere with legitimate WordPress functionality and should be tested before deployment.

Temporary controls should not be considered a replacement for installing the security update.

How to detect possible wp2shell exploitation

Security teams should review web server, reverse proxy, WAF and application logs for unexpected requests involving the affected REST API batch routes.

Relevant indicators may include requests containing:

/wp-json/batch/v1

or:

rest_route=/batch/v1

Requests to these endpoints are not automatically malicious.

Investigators should review:

  • HTTP method
  • Request body
  • Query parameters
  • Response status
  • Response size
  • Source IP address
  • User-Agent
  • Repeated requests
  • Subsequent administrator activity
  • File creation or modification
  • Malicious plugin installs
  • Unexpected outbound connections

Organisations using a WAF or reverse proxy should ensure request bodies and query parameters are logged.

What to check after updating WordPress

Installing the update closes the vulnerability but does not remove an attacker who may have exploited the site before it was patched.

Administrators who identify suspicious activity should investigate for signs of compromise.

Review affected WordPress systems for:

  • Unexpected PHP files
  • Recently modified WordPress Core files
  • Malicious plugins
  • Modified themes or plugins
  • Unknown administrator accounts
  • Suspicious scheduled tasks
  • Malicious cron jobs
  • Database modifications
  • Unexpected redirects
  • Injected JavaScript
  • Web shells
  • New SSH keys
  • Suspicious outbound network connections
  • Access to wp-config.php
  • Credential theft
  • Changes to authentication settings

Where compromise is suspected, consider rebuilding the site from a known-good backup rather than only removing visible malicious files.

Credentials associated with the affected installation should also be rotated.

1. Identify WordPress assets

Create an inventory of all internet-facing WordPress installations, including:

  • Production websites
  • Staging environments
  • Development systems
  • Marketing websites
  • Legacy websites
  • Sites operated by agencies
  • Subsidiary websites
  • Forgotten or abandoned installations

2. Check installed versions

Identify sites running affected WordPress versions.

Do not rely only on version information exposed publicly, as some sites suppress or modify WordPress version metadata.

3. Deploy the security update

Update affected systems to a patched WordPress release.

4. Verify successful installation

Confirm that the updated version is running and that the site remains functional.

5. Review logs

Search for suspicious requests involving the REST batch API and investigate unusual activity.

6. Apply temporary protection where required

Restrict access to the affected endpoints where updates cannot be deployed immediately.

7. Investigate exposed systems

Conduct additional review where vulnerable installations were internet-facing before being patched.

KEVIntel early warning and monitoring

KEVIntel sent an early-warning alert to email subscribers advising them to update affected WordPress installations immediately.

KEVIntel is continuing to monitor:

  • Proprietary honeypot and sensor telemetry
  • Requests targeting WordPress REST API routes
  • Emerging exploitation payloads
  • Internet scanning activity
  • Public proof-of-concept releases
  • Vulnerability scanner templates
  • Threat intelligence reporting
  • Evidence of real-world exploitation

KEVIntel will update its exploitation assessment if credible attacker activity is identified.

Frequently asked questions

What is wp2shell?

wp2shell is the public name given to a critical WordPress Core vulnerability chain that may allow unauthenticated remote code execution.

Does wp2shell require a vulnerable plugin?

No. The reported vulnerability affects WordPress Core and does not require a vulnerable third-party plugin.

Does an attacker need a WordPress account?

No. The vulnerability can reportedly be targeted without authentication.

Has wp2shell been exploited in the wild?

KEVIntel has not confirmed in-the-wild exploitation at the time of publication. But it's only a matter of time.

Is there a working proof of concept?

KEVIntel has independently reproduced the vulnerability and developed a working proof of concept in a controlled environment. The proof of concept is not being publicly released. Attackers will likely do the same.

Should I wait for automatic WordPress updates?

No. Check the installed version manually and confirm that the security update completed successfully.

Is blocking the REST batch API enough?

Blocking access to the affected endpoint may provide temporary risk reduction, but installing the security update remains the recommended remediation.

Conclusion

The WordPress wp2shell vulnerability is a critical security issue that may allow an unauthenticated attacker to achieve remote code execution against affected WordPress installations.

Although KEVIntel has not yet confirmed exploitation in the wild, the vulnerability has been independently reproduced and practical exploitability has been validated.

Because WordPress is widely deployed and the attack does not require authentication, administrators should assume exploitation attempts could emerge quickly.

Update affected WordPress installations immediately and verify that the patched version is running successfully.

References