WordPress Ships 7.0.2 Security Release Patching Two High-Severity Vulnerabilities
WordPress ships the 7.0.2 patch pairing wp2shell with a fresh SQL-injection CVE — defender teams and hosting providers apply immediately this weekend.
The release pairs the previously disclosed wp2shell core RCE with a fresh SQL-injection CVE — turning weekend patch verification into the highest-value task for hosting providers and agencies.
SAN FRANCISCO, CALIF. — WordPress shipped its 7.0.2 security release on July 18, 2026, addressing two high-severity vulnerabilities in the world's most widely deployed content-management system and drawing a blunt instruction from the security press: patch immediately. The release closes CVE-2026-60137, a SQL injection flaw, and CVE-2026-63030 — the REST API batch-route confusion and SQL-injection issue publicly known as "wp2shell" that leads to remote code execution. The first was reported by TF1T, dtro, and haongo; the second by Adam Kues at Assetnote / Searchlight Cyber.
The 7.0.2 announcement continues a patch cycle that began a day earlier, when WordPress shipped fixes for the wp2shell core RCE. Help Net Security, which urged operators to patch immediately, reports that WordPress 6.9 is affected by both flaws while the 6.8 branch is affected only by CVE-2026-60137. WordPress says it is forcing updates to installations with automatic updates enabled.
What WordPress Released
The 7.0.2 release, published July 18, 2026, addresses one critical and one high-severity security issue. CVE-2026-60137 is a SQL injection flaw. CVE-2026-63030 — the issue publicly referred to as "wp2shell" — is described as a REST API batch-route confusion and SQL injection that leads to remote code execution. The CyberSignal is not reconstructing the exploitation path for either flaw; the operative facts are the affected and fixed versions.
WordPress 6.9 is affected by both vulnerabilities and is fixed in 6.9.5. The 6.8 branch is affected only by CVE-2026-60137, the SQL-injection issue, and is fixed in 6.8.6. The 7.0 branch is fixed in 7.0.2, and the 7.1 beta in 7.1 beta2; releases prior to 6.8 are not affected. WordPress said in the 7.0.2 release announcement that it is forcing updates to installations with automatic updates enabled.
For sites that cannot update immediately, Searchlight Cyber's emergency guidance centres on blocking anonymous access to the batch API — via a plugin that blocks unauthenticated REST access, or a web application firewall rule. Both measures may break legitimate functionality and are temporary stopgaps, not substitutes for updating.
Continuation Context: The wp2shell Disclosure and the New SQL-Injection CVE
CVE-2026-63030 is not new to readers of The CyberSignal. The wp2shell flaw was disclosed on July 17 as a critical unauthenticated remote code execution vulnerability in WordPress Core, reachable through the REST API and requiring no valid account. What 7.0.2 adds is the second CVE — CVE-2026-60137, a separate SQL-injection issue from a different team.
One point from the earlier coverage bears repeating, because it is easy to get wrong: there is no public proof-of-concept for wp2shell. Searchlight Cyber withheld the technical exploit details at disclosure, and no working exploit code had been published as of this writing; any reporting that implies a proof-of-concept is circulating is inaccurate. The absence of exploit code is a patch window, not a reprieve — a fix shipped to open-source code also ships a diff.
The pairing also lands in a sustained run of CMS security activity The CyberSignal has tracked. SQL-injection flaws have featured heavily — in Drupal core and in the Ghost CMS issue abused in a ClickFix campaign across roughly 700 sites — while WordPress-side incidents have included the Gravity SMTP plugin API-key exposure and CISA's addition of a Joomla JCE component flaw to its KEV catalog. What sets the 7.0.2 pairing apart is that CVE-2026-63030 sits in WordPress Core — the question is not what was installed but what version is running.
Defender Posture: Verifying the Patch Across Hosted Properties
The remediation instruction is short: update to 6.8.6, 6.9.5, or 7.0.2. What turns that into real work is verification. WordPress says it is forcing updates where automatic updates are enabled, but that carries a condition, and the push may not reach sites where auto-updates were switched off. Administrators should confirm each internet-facing property actually landed on a fixed version rather than assume it arrived: the difference between patch availability and patch verification that recurs in nearly every CMS incident.
The population that has to do this work is broader than a single security team. Digital agencies with hundreds of client sites, hosting providers with fleets in the thousands, and marketing teams running campaign microsites all hold assets in the affected range, rarely in a central inventory. The task is a version query: enumerate every WordPress instance under management, find anything on an affected branch, and confirm the fixed version is running rather than queued — the forgotten microsites least likely to be on the list.
The Researcher-Attribution Note in Context
The two CVEs came from two sources. CVE-2026-60137, the SQL-injection flaw, was reported to the WordPress security team as a team effort by TF1T, dtro, and haongo. CVE-2026-63030 — wp2shell — was reported by Adam Kues at Assetnote / Searchlight Cyber, the same research team credited with the earlier core-RCE disclosure. Both were handled through coordinated disclosure ahead of the 7.0.2 release.
One caution on the public record: Help Net Security's writeup lists both bullet points under CVE-2026-60137, which appears to be a typographical error — the REST API batch-route confusion and RCE issue is tracked as CVE-2026-63030 in the wp2shell disclosure. The CyberSignal uses the distinct identifiers throughout to avoid conflating two separate flaws from two separate teams.
What a CISA KEV Addition Would Signal
As of publication, neither CVE-2026-60137 nor CVE-2026-63030 is confirmed as added to CISA's Known Exploited Vulnerabilities catalog. A KEV listing is the specific event defenders should watch for: it would confirm what is currently unestablished — that at least one flaw is being exploited in the wild — and attach federal remediation deadlines for US civilian agencies under Binding Operational Directive 22-01, converting a recommendation into a compliance clock. A core-level unauthenticated RCE in the web's most-deployed CMS is precisely the profile that draws a KEV entry once exploitation is observed, so the absence of one today should read as "not yet confirmed," not "not a priority."
Open Questions
Several material points remain unestablished. The CVSS scores for both CVEs are not confirmed; the release characterises the pair as one critical and one high-severity issue without a numeric score in the reporting. Whether either flaw is being exploited in the wild is not confirmed, and no such exploitation had been reported at publication.
Whether either CVE will be added to CISA's KEV catalog is likewise unconfirmed. And the total number of affected deployments is not established — the vulnerable population is bounded by branch and version, not WordPress's total install base, since CVE-2026-63030 exists only from 6.9 onward and CVE-2026-60137 from 6.8.
The CyberSignal Analysis
The facts above come from the WordPress release and the reporting. What follows is The CyberSignal's editorial reading of what operators should take from this release; none of it introduces new reported facts.
Signal 01 — A Two-CVE Release Is One Patch Action, Not Two
It is tempting to triage CVE-2026-60137 and CVE-2026-63030 separately — different classes, different severities, different teams. For anyone running WordPress, that is a distinction without an operational difference: both are closed by the same releases, so the action is identical. Teams should resist prioritising the RCE and deferring the SQL-injection flaw; the update that fixes one fixes both, and splitting them only manufactures a second patch cycle that tends not to happen.
Signal 02 — "Forced Updates" Is a Condition, Not a Guarantee
WordPress forcing updates to auto-update-enabled installations is genuinely useful, and for much of the install base it will resolve this quietly. But the phrase carries a load-bearing condition, and the sites that most need patching — bespoke, heavily customised, or deliberately pinned — are exactly the ones most likely to have automatic updates disabled. The responsible posture is to treat the forced-update mechanism as reducing the problem, not eliminating it, and to verify per site rather than assume fleet-wide coverage.
Signal 03 — Watch the Score and the KEV, but Patch on the Characteristics
The numeric CVSS scores for both CVEs are not yet published, and a programme that waits for a score to drive its SLA will lose days it does not have. The attack characteristics already settle it: an unauthenticated, no-interaction path to code execution in WordPress Core is an emergency regardless of what number lands later. A CVSS assignment, an upward revision, a KEV listing — these are confirmations to track, not preconditions to act on.
