WordPress released urgent security updates on July 17, 2026, after researchers disclosed a vulnerability chain involving the REST API batch endpoint. On affected WordPress 6.9 and 7.0 installations, an anonymous attacker could combine a batch-route confusion issue with a separate SQL injection flaw to execute code on the server without logging in.
The WordPress 7.0.2 release notice classifies the two issues as critical and high severity and says site owners should update immediately. The vulnerabilities are tracked as CVE-2026-63030 and CVE-2026-60137.
This article explains the practical risk without publishing a working exploit.
What happened in the WordPress batch API?
The WordPress REST API can group several operations into one batch request. The new route-confusion vulnerability allowed the batch handler to interpret a request differently from the route that ultimately processed it. Researchers found that this behavior could be chained with the SQL injection issue in WordPress query handling.
The important point is the result, not the payload: on vulnerable WordPress 6.9 and 7.0 releases, the chain could lead to unauthenticated remote code execution on a standard WordPress installation. It did not require a vulnerable third-party plugin to complete the full chain. The original Searchlight Cyber research calls the chain WP2Shell and recommends an immediate core update.
The two CVEs also have different version ranges. WordPress 6.8 received a fix for the SQL injection issue, but the full batch-route remote-code-execution chain affects WordPress 6.9 and 7.0 releases listed below.
| Installed branch | Affected releases | Fixed release | Practical exposure |
|---|---|---|---|
| WordPress 7.0 | 7.0.0–7.0.1 | 7.0.2 | Both vulnerabilities; full chain could reach remote code execution |
| WordPress 6.9 | 6.9.0–6.9.4 | 6.9.5 | Both vulnerabilities; full chain could reach remote code execution |
| WordPress 6.8 | 6.8.0–6.8.5 | 6.8.6 | SQL injection issue only; not the full batch-route chain |
| Earlier than 6.8 | Not affected by these two CVEs | Move to a supported current release | Old core may still contain other known vulnerabilities |
What we observed in real traffic
Around the disclosure window, we saw a high volume of requests across many WordPress REST API routes. The requests were not limited to one endpoint or one disclosed core version; they looked like broad automated reconnaissance attempting to identify different WordPress versions and available API behavior.
We also saw malformed batch requests produce fatal REST errors on an older WordPress installation. That evidence matters operationally, but it has a limit: a burst of API probes or an HTTP 500 response does not prove that the new vulnerability chain succeeded, and an older batch-related fatal is not automatically the same issue as CVE-2026-63030.
This distinction is important for incident response. Treat the traffic as a reason to patch and investigate, not as evidence that every scanned site was compromised.
Public exploitation material appeared quickly after disclosure. The MS-ISAC advisory also reports telemetry consistent with automated scanning and exploitation attempts. Waiting for a clear visible symptom is therefore a poor update strategy.
What access could an attacker gain?
Successful exploitation could run code with the permissions of the account used by PHP or the web server. That is serious, but it does not automatically mean root access to the entire server.
The actual reach depends on the hosting configuration and the permissions assigned to that service account. In a typical WordPress environment, an attacker may be able to:
- read or change files that the web process can access;
- steal database or application credentials available to the site process;
- read, change, or delete WordPress database content, including customer or order data where applicable;
- create unauthorized administrator accounts or other persistence;
- inject malicious scripts, redirects, spam, or malware into the site;
- use the compromised site as a foothold against other services accessible from the same account.
The MS-ISAC assessment describes the same boundary: code execution occurs in the context of the affected service account, so least-privilege hosting reduces the blast radius. Shared credentials, writable application files, and over-privileged service accounts increase it.
What site owners should do now
1. Confirm the installed WordPress version
Check Dashboard → Updates, your hosting control panel, or WP-CLI. Do not rely on a cached scanner result or a version hidden from the page source.
2. Install the patched core release
Update immediately to WordPress 7.0.2, 6.9.5, or 6.8.6 for the branch you still operate. If the site runs an older unsupported release, plan a tested move to a current supported version rather than treating its exclusion from these two CVEs as a security guarantee.
Take a current backup and test the update on staging when the site has custom plugins, a custom theme, WooCommerce checkout logic, or old PHP constraints. Do not let a normal compatibility process become an open-ended delay.
3. Review logs and site integrity
Search web access logs for unusual batch-endpoint traffic and bursts across unrelated REST routes. Review PHP and application error logs around the same timestamps. Check for unexpected administrator users, unfamiliar plugins or themes, new scheduled tasks, unexplained redirects, and recently changed PHP files.
Developers with WP-CLI can run wp core verify-checksums to compare core files with WordPress.org checksums. A clean core check is useful evidence, but it does not inspect uploads, custom code, the database, server configuration, or every persistence mechanism.
4. Escalate if you find indicators of compromise
If you find unauthorized users, changed files, malware, unknown scheduled jobs, suspicious outbound traffic, or unexplained database changes, preserve a snapshot and timestamps before cleaning. Restrict access where practical, involve the hosting provider, rotate WordPress, hosting, database, SFTP, and API credentials, and rebuild affected code from known-clean sources.
The official WordPress hacked-site guide recommends documenting symptoms, scanning both the site and local administrator devices, resetting access, keeping a backup of the affected environment for reference, and updating after the installation is clean.
5. Use a WAF rule only as a temporary measure
If a core update cannot be completed immediately, ask the hosting or WAF provider to block anonymous access to the batch endpoint in both normal permalink and rest_route forms. This can break legitimate REST integrations and is only an emergency containment step. The durable fix is the patched WordPress core release.
For WordPress developers and agencies
Treat this incident as a maintenance test, not only a one-off patch:
- inventory the exact core version for every managed site;
- confirm which sites actually received the security update;
- preserve enough access and PHP logs to investigate future API probing;
- run PHP and plugin compatibility checks before upgrades become urgent;
- keep service accounts and database permissions as narrow as the application allows;
- document who owns security updates, backups, monitoring, and incident response.
Mass scanning rarely waits for a maintenance window. A clear inventory and a rehearsed update path are more valuable than a generic security plugin installed without anyone reviewing its alerts.
Need help updating or checking the site?
MerchWeave can help update WordPress safely, check theme and plugin compatibility, review REST and server logs, verify core integrity, and perform a focused security audit for signs of compromise.
Contact MerchWeave about a WordPress update or security audit. Tell us the current WordPress version, hosting setup, and whether you have seen unusual API requests or errors.