root@markcardiff:~/reports$ ./render vuln-brief wp2shell --public-safe

wp2shell: WordPress Core RCE

Public defensive brief on CVE-2026-63030, a WordPress Core vulnerability disclosed on 17 July 2026 and described by the WordPress/GitHub advisory as a REST API batch-route confusion weakness combined with SQL injection leading to remote code execution.

Published 2026-07-18 18:20 UTC

Focus vulnerability brief

Product WordPress Core

Status patch now

CriticalGitHub advisory severity

6.9.0-6.9.4affected 6.9 branch

7.0.0-7.0.1affected 7.0 branch

6.9.5 / 7.0.2fixed releases

Executive summary

CVE-2026-63030, informally tracked as wp2shell, is a critical WordPress Core issue affecting modern WordPress branches 6.9 and 7.0. The public advisory states that a REST API batch-route confusion weakness, when combined with a separate SQL injection issue, can lead to remote code execution.

The operational risk is high because exploitation is reported as unauthenticated, does not require a plugin, and targets software commonly exposed directly to the internet. Rapid7 reported no publicly confirmed in-the-wild exploitation at publication time, but also assessed that public proof-of-concept development is likely in a short period because WordPress Core is open source.

Defender priority is simple: confirm every public WordPress estate item is below the affected range or has upgraded to 6.9.5, 7.0.2, or a later fixed branch. Do not rely on automatic updates without verification.

Conceptual risk chain based on public WordPress/GitHub and Rapid7 reporting. Not an exploit guide.

Key facts Timeline Exposure and impact Defensive actions SOC watchpoints Limitations Sources

Key facts

Item	Public-source position	Defensive interpretation
Identifier	`CVE-2026-63030` / `GHSA-ff9f-jf42-662q`.	Track both identifiers in vulnerability-management and exposure-management workflows.
Root issue	REST API batch-route confusion combined with SQL injection leading to remote code execution.	Internet-facing WordPress should be treated as remotely exploitable until version status is verified.
Affected versions	WordPress `6.9.0-6.9.4` and `7.0.0-7.0.1`.	Earlier-than-6.9 branches are reported by Rapid7/GitHub as not affected by this CVE; still check for other WordPress security updates.
Fixed versions	`6.9.5`, `7.0.2`, and `7.1 beta2` include fixes.	Patch to the current stable maintained branch where possible rather than making this a one-off point upgrade.
Authentication	Rapid7 reported the issue as unauthenticated and requiring no user interaction.	Prioritize public sites, shared hosting, marketing sites, and forgotten subdomain WordPress installs.
Exploit status	Rapid7 reported no publicly confirmed in-the-wild exploitation at its publication time.	Absence of public exploitation is not a safe waiting condition; open-source diffing may shorten exploit-development time.

Timeline

2026-07-17 19:00 UTC: GitHub advisory GHSA-ff9f-jf42-662q published for CVE-2026-63030.

2026-07-17: WordPress 7.0.2 released as a security update addressing one critical and one high-severity issue; forced auto-updates enabled for affected versions that support them.

2026-07-17: WordPress 6.9.5 released as a backport for the affected 6.9 branch; WordPress 7.1 beta2 also includes fixes.

2026-07-17: Rapid7 published an Emergent Threat Response brief and stated workarounds were not recommended at that time.

2026-07-18: This public defensive report published for SOC triage and estate-owner communication.

Exposure and impact

Trust boundary: unauthenticated internet requests crossing into WordPress REST API handling.
Impact: potential remote code execution in the web application context, with likely paths to content tampering, credential theft, malware placement, spam/SEO injection, webshell persistence, or pivoting into adjacent hosting resources.
Blast radius: highest for multi-site hosting, shared database credentials, writable plugin/theme directories, weak filesystem permissions, or reused admin credentials.
Exploitability: high in principle because no account or plugin dependency is reported; exploit maturity should be monitored closely.

Who should move first

Internet-facing WordPress sites on versions 6.9.0 through 6.9.4 or 7.0.0 through 7.0.1.
Sites where automatic background updates are disabled, blocked by file permissions, or managed by a third-party host without direct verification.
High-value public sites: customer portals, login-enabled sites, payment-adjacent content, high-traffic marketing properties, and sites with privileged integrations.
Any WordPress host with abnormal REST API traffic, recent unexpected file writes, new admin users, or changed plugin/theme files.

Defensive actions

Inventory all public WordPress assets, including subdomains, campaign microsites, legacy hosting panels, and agency-managed sites.
Upgrade affected 6.9 branch sites to 6.9.5, affected 7.0 branch sites to 7.0.2, or to a later fixed stable release where supported.
Verify the effective version after update; do not assume the forced auto-update has completed successfully.
Take backups before emergency patching where operationally feasible, but do not let backup process delays become a patch blocker for exposed affected sites.
Review WAF, reverse proxy, and web server logs for unusual REST API batch endpoint activity and spikes in unauthenticated API requests.
After patching, perform a basic compromise review: unexpected admin users, plugin/theme changes, newly modified PHP files, suspicious scheduled tasks, unknown outbound connections, and unfamiliar files under writable web directories.
If compromise indicators exist, preserve logs and filesystem evidence before cleaning; rotate WordPress admin credentials, database credentials, API keys, and hosting-panel credentials as appropriate.

SOC watchpoints

Unexpected request volume to WordPress REST API paths from unauthenticated sources.
HTTP 500/502/403 bursts around REST API requests followed by successful responses or admin login activity.
New or modified PHP files in WordPress root, theme, plugin, upload, cache, or temporary directories.
Creation of new WordPress administrator accounts or password resets not tied to known maintenance windows.
Outbound connections from web hosts to unfamiliar infrastructure after suspicious web requests.
Endpoint telemetry for web server child processes launching shell, interpreter, archive, download, or network utilities.

Hardening notes

Keep WordPress core, plugins, and themes on maintained branches; Core patching does not cover plugin/theme exposure.
Restrict filesystem write permissions where practical, especially for code directories.
Place high-value WordPress sites behind a managed WAF or reverse proxy with logging enabled; treat WAF as compensating control, not remediation.
Disable XML-RPC if unused and reduce exposed admin surface with SSO/MFA, IP allowlisting where feasible, and strong role hygiene.
Ensure web and database credentials are unique per site to limit blast radius if one host is compromised.

Limitations

This report is based on public reporting available at publication time. It intentionally omits exploit procedure and payload-level detail. Public sources reviewed did not provide a confirmed exploitation-in-the-wild case at Rapid7 publication time, and that status can change quickly. Estate owners should treat patch verification and log review as urgent rather than waiting for exploitation confirmation.