Download the latest Vulnerability & Exploitation Report

Download now

CrowdSec

VulnTracking

CVE-2026-63030 WordPress WP2Shell Exploitation: 62,802 Attacking IPs Observed by CrowdSec

CVE-2026-63030 is a CVSS 9.8 REST API batch-route confusion flaw in WordPress core 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. Chained to CVE-2026-60137, it lets an unauthenticated attacker read the database and reach remote code execution. CrowdSec observed 62,802 unique IP addresses sending matching requests over the last 15 days. Upgrade to 7.0.2 or 6.9.5.

CVE-2026-63030 at a glance

  • Affected: WordPress core 6.9.0 through 6.9.4, and 7.0.0 through 7.0.1
  • Fixed in: 6.9.5 and 7.0.2 (July 17, 2026), plus 7.1 Beta 2
  • Vulnerability class: REST API batch-route confusion (CWE-436) chained to blind SQL injection in WP_Query via CVE-2026-60137. CrowdSec CTI records the tracked exploitation pattern under CWE-89.
  • Severity: CVSS 9.8 Critical
  • Authentication required: None
  • Public exploit: Yes. Searchlight Cyber published full technical details, multiple proof-of-concept exploits are circulating, and a Nuclei template is public.
  • CISA KEV: Added July 21, 2026; remediation deadline July 24, 2026
  • CrowdSec detection rule live since: July 20, 2026
  • First exploitation attempt observed: July 20, 2026
  • Exploitation phase: Active Exploitation (raised from Rapid Escalation on August 17, 2026)
  • Observation window used here: Signal counts cover July 20 to August 22, 2026 (34 days). The unique-IP count is a rolling 15-day window ending August 23, 2026.

Key findings

  • CVE-2026-63030 went from publication to CISA KEV in four days: WordPress shipped 6.9.5 and 7.0.2 on July 17, 2026. CrowdSec’s detection rule went live on July 20 and matched traffic the same day, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on July 21 with a July 24 deadline. There was no quiet period in which to schedule the patch.
  • 62,802 unique IP addresses in 15 days, the highest count of any CVE we track: That rolling 15-day figure puts CVE-2026-63030 ahead of the previous leader, the NETGEAR DGN1000 command injection flaw CVE-2024-12847, which recorded 51,404 unique addresses over the same window. Across the longer 34-day window, the network logged 3,147,518 signals, averaging 92,574 a day and peaking at 158,259 on July 26.
  • The attack takes one HTTP request and no credentials: A single POST to the REST API batch endpoint nests sub-requests that dispatch under the wrong handler, bypassing the permission check that should stop an anonymous caller. With a public proof-of-concept and a Nuclei template circulating since July, the skill floor is close to zero.
  • Daily signal volume is flat while the source population keeps growing: Signals have held roughly steady since late July, but distinct sources per day rose from about 1,900 in the first week to 10,486 on August 21. The chart understates this, because four times as many machines now send a similar total volume between them.

What is WordPress, and who is exposed to CVE-2026-63030?

WordPress is the content management system behind more than a third of the web. The people responsible for an install are usually marketers, agencies, small-business owners, and developers rather than a security team, which matters here because CVE-2026-63030 requires a version check on every site someone owns, including the ones they inherited and stopped thinking about.

Why CVE-2026-63030 matters: The flaw is in WordPress core, so no unusual plugin or configuration is needed to be exposed. A successful chain reads the database directly, including usernames and password hashes, then reaches remote code execution on the underlying server. For an online shop, that means the storefront, the customer list, and the hosting account are all reachable through the same request.

Among the organizations whose machines reported these attempts to the CrowdSec Network, 65% are in commerce, and 30% are small offices or home setups, while education accounts for 3% and government, healthcare, and financial services barely register. The reporting organizations cluster in Germany (24%), South Africa (22%), the United States (15%), and France (10%). This describes where CrowdSec has visibility, not where WordPress is deployed globally.

How does CVE-2026-63030 work?

The WordPress REST API batch endpoint lets a client send several sub-requests inside one HTTP call, and it has shipped in core since version 5.6 in 2020. It validates and executes those sub-requests in separate loops, and CVE-2026-63030 is the interpretation conflict between the two: a crafted request dispatches under a different handler than the one that was validated, so an anonymous caller reaches /wp/v2/categories without passing the permission check.

That route sits on top of CVE-2026-60137, a blind SQL injection in how WP_Query handles the author__not_in parameter. Attackers place conditional SLEEP() statements in author_exclude and time the response: a fast reply means the condition was false, a slow one means it was true. Repeating that request extracts the database one bit at a time, which is slow but entirely automatable. The root cause is that validation and execution in the batch processor do not agree on which route a sub-request belongs to.

CVE-2026-63030 is only critical because CVE-2026-60137 exists to receive the redirected request. Neither bug reaches remote code execution alone, which is why patching core closes both halves at once.

What is the CrowdSec Network observing for CVE-2026-63030?

Between July 20 and August 22, 2026, the CrowdSec Network recorded 3,147,518 signals from machines reporting requests that match the CVE-2026-63030 exploitation pattern, detected by the CrowdSec scenario released on July 20, 2026. That averages 92,574 signals per day, peaking at 158,259 on July 26. Over a separate rolling 15-day window ending August 23, the network counted 62,802 unique IP addresses sending matching requests.

The source mix has changed since our Week 31 alert. In July, sources concentrated in the United States and Iran. Over the current window, the United States accounts for 28%, Bulgaria for 16%, and the Netherlands for 14%, with Iran down to 6%. Bulgaria and the Netherlands are dense in cheap VPS capacity rather than residential broadband, which is consistent with rented infrastructure rather than a consumer botnet. Of the intent our CTI classifies, 93% is infrastructure takeover, against 5% data exfiltration and 2% ransomware.

The part worth flagging is the divergence between the two curves. Most CVEs we track spike and then decay as easy targets get patched. CVE-2026-63030 spiked on July 26, then plateaued in volume while distinct sources per day quadrupled. That is consistent with an exploit spreading into many scanning toolkits rather than being run hard by a few operators, and it is a worse position for defenders than the spike, because a spike ends on its own.

What this data does not show

  • A matching request is an exploitation attempt. CrowdSec cannot confirm that any of them succeeded, and none of these figures represent confirmed compromises.
  • 62,802 unique IP addresses is not 62,802 threat actors. A single operator rotating through rented cloud ranges inflates the count, and one address can be shared by many users.
  • These counts come from traffic reaching machines participating in the CrowdSec Network: a sample of internet-wide activity, not a census. The geographic breakdown reflects where CrowdSec has visibility.
  • The scenario matches requests against the CVE-2026-63030 pattern and cannot reliably separate a vulnerability scan from a genuine exploitation attempt, nor a security researcher from an attacker.
  • The signal window and the unique-IP window differ, so the two headline numbers cannot be divided into each other.

What defenders get wrong about CVE-2026-63030

The common mistake is blocking /wp-json/batch/v1 at the edge and calling it handled. Most public writeups describe the endpoint in that form, so that is the string that ends up in WAF rules and firewall configs. The traffic CrowdSec actually observes overwhelmingly uses the query-string form, /?rest_route=/batch/v1, which reaches the same REST route and sails past a path-based block. If you added an edge rule in July and have not tested it against the rest_route variant, assume it is not covering you.

The second mistake is trusting automatic updates without verifying them. WordPress enabled forced automatic updates for this release, and for most sites that worked. Five weeks in, tens of thousands of addresses are still finding sites where it did not, usually because updates were disabled for stability, the host version-pins the site, or it is a staging copy nobody owns. Verification takes seconds.

Where this reasoning has limits: blocking at the edge is a stopgap, not a fix. Filtering the batch endpoint may break legitimate integrations that use batch requests, and it does nothing about CVE-2026-60137 reached by another path. Patch first; use the request-level controls below to buy time, not to replace the upgrade.

How do you protect WordPress against CVE-2026-63030?

Patch. Upgrade WordPress to 7.0.2 or 6.9.5 or later (release notes, advisory). Confirm the running version rather than assuming, in the admin dashboard under Updates or with wp core version if you use WP-CLI. Repeat the check on staging copies, managed hosts, and client sites.

Virtual patching with CrowdSec AppSec. Until you can patch, the CrowdSec AppSec Component inspects HTTP requests at the remediation component before they reach WordPress and returns a block decision when a request matches a rule. The relevant rule is crowdsecurity/vpatch-CVE-2026-63030, which detects the batch route confusion and the related author_exclude blind SQL injection attempts.

sudo cscli collections install crowdsecurity/appsec-virtual-patching

sudo systemctl reload crowdsec

sudo cscli appsec-rules list | grep -i 'vpatch-CVE-2026-63030'

Working correctly, a matching request gets an HTTP 403 from the remediation component, and the decision appears in cscli alerts list. Unlike a path-based edge rule, this inspects the resolved REST route, so it covers both the /wp-json/ and ?rest_route= forms.

Preemptive blocking. Subscribe to the CrowdSec Intelligence Blocklists to drop addresses already seen attacking the network. This covers known infrastructure and will not stop a first-seen address, which matters more than usual given how fast the source population is growing.

Stay proactive. Follow CVE-2026-63030 on the Live Exploit Tracker and query its sources in CrowdSec CTI.

Sharing insights and taking swift action can collectively reduce the impact of these threats. This is your call to action for real-time threat intelligence and collaborative cybersecurity.

Full report, with the complete fact block, FAQ and sources: https://www.crowdsec.net/vulntracking-report/cve-2026-63030-wordpress-wp2shell-sqli-to-rce

If you’re already subscribed, feel free to like and share this post to help your network stay informed about current threats.

WRITTEN BY