WordPress Core RCE Vulnerability CVE-2026-63030 Patched

Originally published on CyberNetSec.

Executive Summary

A critical unauthenticated remote code execution (RCE) vulnerability, tracked as CVE-2026-63030, has been identified in WordPress Core. The flaw allows an attacker with no authentication to execute arbitrary code on a vulnerable website, potentially leading to a full server compromise. The vulnerability impacts a wide range of recent WordPress versions. Security updates have been released, and immediate patching is strongly recommended for all affected sites. Given the widespread use of WordPress, this vulnerability poses a significant threat to millions of websites.

Vulnerability Details

CVE-2026-63030 exists in the WordPress REST API batch processing endpoint. An unauthenticated attacker can send a specially crafted request to this endpoint to trigger the RCE. According to researchers at Searchlight Cyber who discovered the flaw, it is exploitable in a default WordPress installation without any third-party plugins. The attack vector is reachable when a persistent object cache is not in use, which is a common configuration.

While the GitHub Security Advisory rated the flaw as critical, it was initially assigned a CVSS v3.1 score of 7.5. However, security analysts note that unauthenticated RCEs typically warrant a higher score, and the risk should be considered critical regardless of the current score.

Affected Systems

The vulnerability affects the following versions of WordPress Core:

• 6.9.0 through 6.9.4
• 7.0.0 through 7.0.1

Exploitation Status

As of this report, there are no public reports of active exploitation in the wild. However, due to the unauthenticated nature of the vulnerability and the detailed information available, security experts anticipate that a functional proof-of-concept (PoC) exploit will be developed and released publicly in the near future. This will likely lead to widespread automated scanning and exploitation attempts.

Impact Assessment

A successful exploit of CVE-2026-63030 results in a complete compromise of the target WordPress site. An attacker can execute arbitrary code on the underlying server, which allows them to:

• Steal sensitive data from the website's database (e.g., user information, customer orders).
• Deface the website or inject malicious content.
• Install backdoors for persistent access.
• Use the compromised server to host malware, launch phishing campaigns, or attack other systems.
• Deploy web shells or cryptocurrency miners.

Cyber Observables — Hunting Hints

The following patterns may help identify attempts to exploit this vulnerability:
| Type | Value | Description |
|---|---|---|
| url_pattern | /wp-json/v1/batch | Monitor for an unusual volume of POST requests to the REST API batch endpoint, especially from unknown IP addresses. |
| log_source | Web Server Access Logs | Look for POST requests to the batch endpoint that result in HTTP status codes like 500 (Internal Server Error) or have unusually large payloads. |
| file_path | /wp-content/uploads/ | Monitor for the creation of non-image files (e.g., .php, .sh) in the uploads directory, which could be a sign of a successful RCE. |

Detection Methods

• Version Scanning: Use tools like WPScan or other vulnerability scanners to identify all WordPress sites in your environment running the affected versions.
• D3FEND: Network Traffic Analysis (D3-NTA): Analyze web server and WAF logs for suspicious requests targeting the /wp-json/v1/batch endpoint. Create alerts for multiple attempts from a single IP or requests containing suspicious strings.
• File Integrity Monitoring (FIM): Deploy FIM on WordPress core directories and the wp-content folder to alert on any unauthorized file modifications or creations, which could indicate a web shell has been planted.

Remediation Steps

1. Update Immediately: The primary and most effective remediation is to update to a patched version of WordPress. The fixes are included in:
   • WordPress 6.9.5
   • WordPress 7.0.2
   • WordPress 7.1 (Beta) WordPress's automatic update feature should handle this for most sites, but manual verification is crucial.
2. Apply Virtual Patching: If immediate updating is not possible, use a Web Application Firewall (WAF) to create a rule that blocks or logs all requests to the /wp-json/v1/batch endpoint. This can serve as a temporary compensating control.
3. Review for Compromise: After updating, review the site for signs of compromise, such as unexpected admin users, modified files, or suspicious database entries.