A newly documented attack chain named WP2Shell combines two WordPress Core vulnerabilities to move from an unauthenticated web request to administrator access and server-side code execution. The technique can create a privileged account, upload a plugin containing a web shell and leave attackers with a durable command interface on the underlying host.

Seqrite researchers published their analysis on October 16, detailing how CVE-2026-63030 and CVE-2026-60137 reinforce each other. Their work demonstrates a serious path against unpatched sites, although it does not establish widespread exploitation in the wild.

Two flaws create one dangerous path

CVE-2026-63030 affects the WordPress REST API batch controller at /wp-json/batch/v1, which is designed to process several API operations in one submission. According to the research, specially nested requests can confuse route handling and reach behavior that should require authentication. This issue provides access to the next vulnerable code path but does not directly execute commands on its own.

CVE-2026-60137 is an SQL injection weakness in the posts endpoint. The public author_exclude parameter maps to author__not_in in WP_Query, where insufficient input handling can alter a database query. Chained through the route flaw, an external attacker can reach this condition without first signing in.

The combined proof of concept turns database access into an administrator-level foothold and then code execution. The distinction matters for defensive analysis: neither vulnerability should be simplified as a standalone web shell. The takeover is possible because the authentication bypass path exposes the injection weakness and the resulting privileges enable plugin installation.

What the attack leaves behind

Seqrite’s demonstrated sequence creates an unexpected administrator, stages a ZIP file beneath the uploads directory, extracts PHP content through the upgrade area and moves a generated plugin into wp-content/plugins. The plugin then acts as a web shell that can execute operating-system commands.

Useful indicators include temporary files matching temp-write-test-*, archives such as wp2shell_4e9b3641.zip, directories named wp2shell_<hex>, and similarly named PHP files. Defenders should also review traffic to the batch endpoint and look for new administrators whose creation time does not match a legitimate change.

Web-server processes may legitimately write files during plugin installation, so a process such as httpd.exe touching WordPress directories is not proof by itself. Stronger evidence comes from the distinctive naming patterns, an unusual request sequence, unauthorized accounts and PHP files that do not match an approved plugin release.

Affected releases and defensive steps

The report lists WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 as vulnerable to the complete chain. Versions 6.8.0 through 6.8.5 are affected by the SQL injection component. WordPress 6.8.6, 6.9.5 and 7.0.2 are identified as fixed versions; later supported releases should also contain the corrections.

• Upgrade to the appropriate fixed branch or a later supported WordPress release and confirm the update completed.
• Search access logs for suspicious nested requests to /wp-json/batch/v1.
• Review administrator accounts and investigate any unexplained additions.
• Compare plugin, cache, uploads and upgrade directories with known-good baselines.
• Hunt for WP2Shell filename patterns and newly written PHP files.

Restricting unauthenticated access to sensitive REST functionality may reduce exposure in some environments, but it is not a replacement for patching. Internet-facing sites behind managed hosting or an edge security service should still verify the actual WordPress Core version rather than assuming the provider applied the update.

If indicators are present, preserve logs and filesystem evidence before removing artifacts. Disable malicious plugins, rotate WordPress and infrastructure credentials, and investigate for persistence outside the web root. A site that now reports a patched version may still contain accounts or code installed before the upgrade, so remediation must address both the original vulnerabilities and the consequences of earlier access.