Emergency WordPress 6.8–7.0 Updates: Both CVEs Are in KEV, and Public wp2shell Evidence Reaches SQLi

1 Update the maintenance branch before debating wp2shell

The remediation decision fits in the first ticket: update WordPress 6.8.0–6.8.5 to 6.8.6, 6.9.0–6.9.4 to 6.9.5, and 7.0.0–7.0.1 to 7.0.2. WordPress places the 6.8 line only inside the official range for CVE-2026-60137. The 6.9 and 7.0 lines fall inside both CVE-2026-60137 and CVE-2026-63030, and those are the two lines for which WordPress states the combined remote-code-execution result. CISA added both CVEs to KEV on July 21: CVE-2026-63030 carries a July 24 due date that had passed when this report was updated, and CVE-2026-60137 carries an August 4 due date. An affected site needs the complete fixed maintenance release or a vendor-equivalent build with an auditable backport identity.

WordPress shipped all three fixed lines on July 17, 2026, and enabled a forced automatic update for affected versions. "Enabled" describes an action taken by the update service. Asset owners still need per-site evidence that the package downloaded, reached disk, replaced every request-serving process, and updated rollback sources. Organizations subject to CISA requirements should treat the missed July 24 date as a trigger for immediate rollout, a recorded overdue exception, and investigation of the exposure window. Other organizations should also treat KEV as an external known-exploitation priority signal. For WordPress 7.1 test assets, beta 2 is the specifically documented fixed prerelease; production closure should use a maintained formal release. Releases before 6.8 sit outside these two advisory ranges, while their support status and exposure to other vulnerabilities remain a separate lifecycle problem.

KEV currently answers one question: both vulnerabilities have known exploitation. Both CISA ADPs changed SSVC exploitation to active on July 21: CVE-2026-60137 records Automatable=no and Technical Impact=total, while CVE-2026-63030 records Automatable=yes and Technical Impact=total. The July 17 none values remain only as the historical state before that turn. Public technical reproducibility stays in a separate field: the pinned historical detector supports unauthenticated time-based blind-SQL-injection reachability, the current detector observes route-confusion behavior only, and the public record supplies no replay transcript spanning SQL injection, persistence, and RCE. Version, artifact, and runtime acceptance close remediation; the two detector generations support different investigative levels.

2 How one anonymous request reaches the SQL boundary

The front half can be explained in six plain steps before returning to source details. The pinned historical PR #16596 template and fixed source jointly reach the SQL-injection boundary at step six. The current #16658 detector stops earlier at route-confusion behavior and sends no SQL condition or timing probe. WordPress supplies the official conclusion that the two CVEs combine to remote code execution; the database-to-code-execution mechanism beyond step six lacks an independently verified complete implementation in the record used here.

1. The batch endpoint accepts ordered subrequests. An anonymous client places multiple REST operations into /batch/v1. The server retains the original request sequence, route-match state, and validation state. Later processing uses a shared positional index to join those three views of each member.

2. One preparation error leaves the state sequences at different lengths. In affected serve_batch_request_v1(), an early WP_Error enters only $validation; the corresponding $matches position is absent. From that point forward, the same numeric index can retrieve state belonging to different original subrequests.

3. A nested subrequest reopens a top-level serving lifecycle. The batch is already running inside dispatch(), yet affected integration and server entries can enter top-level serving behavior again. The internal item crosses the dispatch context that owns it, adding a second conflict among route matching, parameter registration, and later members.

4. A public parameter reaches the posts controller's query context. The historical ProjectDiscovery PR #16596 layout places a categories request carrying author_exclude inside the nested batch and uses the preceding state conflicts to deliver that value under the posts controller. Pinned WordPress 7.0.1 source shows the posts controller mapping public author_exclude to internal author__not_in at lines 239–270.

5. The query layer lets a scalar avoid per-member integer conversion. A cache-key cleanup introduced with WordPress 6.8 normalized arrays only. A scalar retains its original text until a late cast wraps it in a one-element array for joining. The late container change cannot recover the element conversion that the scalar already skipped.

6. The historical public detector observes a blind-SQL condition at this point. The pinned PR #16596 template uses structurally equivalent false- and true-condition requests and requires HTTP 207, a specific error marker, and a true-case duration of at least seven seconds. A complete positive flow supports unauthenticated time-based blind-SQL-injection reachability. The template extracts no data and performs no later code execution. Multiple false-negative reports filed on July 22 state that the third SQLi request does not execute under some conditions, so a historical non-match records one unsatisfied flow. ProjectDiscovery replaced this flow with the route-confusion template on July 24.

The same sequence explains the version split. The query-shape regression first shipped in 6.8.0, so 6.8.0–6.8.5 need the CVE-2026-60137 repair on their own. The relevant REST batch change first shipped in 6.9.0, and the official ranges begin overlapping there. The fixed 6.8.6 tree carries two extra REST changes in a grouped backport, showing that maintainers moved the code into that line. WordPress still excludes 6.8 from the published CVE-2026-63030 range. Source state and advisory scope answer separate operational questions and should be recorded separately.

2.1 Position arrays and the service lifecycle preserve request identity

The batch index is a relationship key. A later loop traverses original requests and uses $i to read $matches[$i] and $validation[$i]. An internal request that failed during preparation still needs a position in both sequences. Once one position disappears, the ith route match and ith validation result can describe different requests. Fixed code stores the same error object in both sequences. It preserves response cardinality and keeps every error, null placeholder, or ordinary result attached to the member that produced it.

The require-all-validate behavior supplies an ordinary control. When a batch requests complete validation and an error occurs, WordPress returns an error or null for each position and keeps later members in place. Acceptance should therefore observe response count and positional ownership. Rejecting every batch that contains an error could hide the alignment defect while breaking valid protocol behavior. A crash-free request records runtime survival; positional comparison separately establishes whether request, match, and validation state stayed associated.

The dispatch guards protect ownership at another scale. rest_api_loaded() is WordPress's outer REST integration entry, serve_request() is the server's serving entry, and dispatch() handles a request object inside active matching and validation state. The fixed release checks is_dispatching() at the first two entries. During an active internal dispatch, the integration function stops early and the server method returns false. A legitimate subrequest stays in its current dispatch, and top-level constants, initialization, response output, and termination behavior retain their original single lifecycle.

2.2 The query repair sends every processed shape through one integer list

CVE-2026-60137 came from a change with a legitimate cache goal. WordPress changeset 59766, represented by Git commit c22e267ccae50b45e9ae6e4b1e55ce68c408f842, entered trunk in February 2025 and first shipped in 6.8.0. For an array-shaped author__not_in value, it removed duplicates, applied absint to each member, sorted the list, and wrote normalized state back so semantically equivalent inputs could share stable cache semantics. A scalar bypassed the is_array() branch. Only when implode() was about to join the list did (array) wrap the scalar, leaving the member's original text unchanged.

WordPress 6.7.2 is an effective historical control. Its older sequence casts to an array first and then applies an absolute-integer conversion to each member, giving scalar and array forms the same element treatment. WordPress 6.8.0 contains the shape-dependent branch, and commit ancestry agrees with the advisory's lower boundary. The neighboring author__in path also continued converting each member across input shapes. Together those comparisons locate the broken property in author__not_in handling. The source documentation calls the argument int[]; the general runtime entry demonstrably processes a scalar as well, so the boundary nearest SQL has to constrain every runtime shape it accepts and uses.

The fixed implementation retains the outer ! empty() gate and sends strings or arrays that enter the branch through wp_parse_id_list(). Strings split on commas or whitespace, array input retains scalar members, each retained member passes through absint, and duplicates are removed. WP_Query continues only when the parsed list is nonempty. It then sorts the identifiers, builds the author-exclusion condition from integers, and writes back the normalized query state. When parsing produces an empty list, the clause and its associated writeback are absent.

There are two empty paths. An empty string, string zero, integer zero, or an empty array ends at the outer gate and never calls the parser. A whitespace-only string or a nonempty array containing no retained scalar members can enter the branch and then parse empty. Fixed WordPress preserves compatibility-oriented conversion: an ordinary nonnumeric scalar can become integer zero, and a negative value becomes a nonnegative integer. Acceptance should establish that original nonnumeric text no longer survives into query state or SQL-list syntax, equivalent lists converge, and legitimate author filtering still behaves as intended. Requiring every malformed value to return a request error would test a contract the fixed implementation does not promise.

3 Record known exploitation, official RCE, public SQLi, and the unverified tail separately

3.1 The historical template pins SQLi; the current template reports route confusion

The WordPress repository advisory makes a clear product statement for 6.9.0–6.9.4 and 7.0.0–7.0.1: the REST API batch route confusion in CVE-2026-63030 combines with the author__not_in SQL injection in CVE-2026-60137 to produce remote code execution. The maintainer advisory establishes the product outcome; pinned fixed source establishes the three restored program properties. Together, those evidence classes determine update priority and the acceptance target.

Searchlight Cyber named its result wp2shell and reported pre-authentication triggering on a stock, plugin-free WordPress installation with no other preconditions, while withholding the technical details during the update window. Cloudflare's coordinated account limits the anonymous path it describes to WordPress 6.9 or later without a persistent object cache. WordPress's default object cache is request-local unless a site installs a persistent implementation, so a stock plugin-free installation normally fits that Cloudflare environment description. Cache state helps an investigator interpret attributed disclosure conditions. Official version scope continues to decide remediation.

On July 18, ProjectDiscovery merged PR #16596. The historical template pinned at 9e6cb912c9d4df492b68ac0ecf8c333e2357de06 references both CVEs and records validation against vulnerable and fixed targets. It fingerprints WordPress and sends structurally equivalent false- and true-condition groups to POST /?rest_route=/batch/v1. The false-condition step requires HTTP 207 and parse_path_failed; the true-condition step additionally requires JSON and a response duration of at least seven seconds. The template sets no maximum duration for the false condition and calculates no duration delta. Its positive evidence level is a contributor-validated unauthenticated time-based blind-SQL-injection detector. SOSEC did not rerun this historical template, so upstream validation remains attributed to ProjectDiscovery and the contributor.

On July 22, a contributor reported multiple false negatives in PR #16596 and issue #16629 and described conditions under which the third SQLi request never executes. On July 24, ProjectDiscovery used PR #16658 head 5d14aeb15ba2ba90ebcffa97723b63150658a97d to replace the timing/SLEEP SQLi flow with a deterministic route-confusion probe. The contributor reported expected results in a development environment and on the live targets that had produced the false negatives, and issue #16629 closed as completed with the replacement. The main state pinned for this report is d51e9a38ae587ccdf7a75fe6aa0e11c81e7d7972, where the template contains a two-request flow.

The current template first uses WordPress markers in a GET response as an internal gate, then sends one batch POST with no SQL parameter. A positive result requires HTTP 207, JSON, block_cannot_read, and absence of the fixed-routing marker rest_term_invalid; its metadata states that the probe executes no SQL and uses no timing oracle. A current positive supports route-confusion behavior under that layout. A current negative records one run in which the fingerprint, request execution, and four matchers did not all align. The historical three-request positive supports SQL-injection reachability, while the historical negative carries the separate issue #16629 false-negative limit. Preserve different records for each generation: author_exclude, three responses, durations, and third-request execution for the historical template; the GET gate, batch response, and four matcher outcomes for the current template. Data extraction, unintended code execution, and compromise require their own evidence.

3.2 The public tail implementation remains a code claim

Public commit 98716c82d2fe9b84ff15e5f6e7aa90d30927d602 describes a later implementation that uses timing observations to recover values, reuses WordPress state, attempts administrator creation, and then attempts plugin upload and activation. The pinned file is specific enough to review the intended functions and control flow. The repository supplies no successful transcript or CI result, SOSEC did not run the implementation, and the adopted record contains no independent reproduction. Its current evidence level is a concrete, reviewable, unverified tail implementation. It cannot serve as a production indicator or as an independent successful reconstruction of complete wp2shell.

Remediation remains urgent. CISA lists both vulnerabilities as known exploited, the product maintainer supplies the combined RCE finding, the historical ProjectDiscovery positive reaches unauthenticated blind SQL injection, and the current flow supplies a narrower route-confusion signal. Defenders first establish which official interval contains an asset and then install the fixed release for that branch; a non-match from either detector generation remains unresolved. Incident responders keep a precise ladder: an edge request can establish scanning or an attempt; a current-template positive can establish route-confusion behavior; a complete historical timing flow can establish SQL-injection reachability; reliable evidence that the server executed unintended code establishes RCE; unauthorized data access, execution, or control establishes compromise. Every step is assigned from observed records.

CISA's state made a clear turn over four days. The SSVC containers for both CVEs recorded exploitation as none at their respective late-July-17 timestamps; those values now serve only as the historical analysis before the turn. On July 18, BleepingComputer relayed Benjamin Harris and watchTowr's statement that the team was seeing "first signs." The report supplied no telemetry, IOC, victim, request classification, or successful result, leaving that observation unclassified. On July 21, CISA added both CVEs to the raw KEV catalog. The updated ADP for 60137 records Exploitation=active, Automatable=no, and Technical Impact=total; the 63030 ADP records Exploitation=active, Automatable=yes, and Technical Impact=total. This report uses KEV raw catalog version 2026.07.24, released at 2026-07-24T17:40:56.0086Z. The current defense state is "both known exploited"; CISA due dates are July 24 for 63030 and August 4 for 60137.

The KEV entries and both active ADPs establish known exploitation and a government remediation date for each CVE. Public technical reproducibility remains a separate record: no public, successful, replayable transcript currently spans SQL injection, persistence, and RCE, and the adopted sources do not identify which layer the events supporting KEV reached. Asset remediation proceeds immediately from KEV and official version scope. A specific incident still requires its own classification among scanning, route confusion, SQL-injection reachability, RCE, and compromise.

4 The repair must pass both code-property and runtime acceptance

4.1 The maintenance line decides which properties to test

WordPress 6.8 acceptance is query-specific. In an isolated environment, compare a production-equivalent 6.8.5 artifact with 6.8.6 using ordinary integer arrays, numeric scalars, a nonnumeric placeholder, duplicate members, and reordered lists. The fixed artifact should converge on integer semantics; original nonnumeric text should disappear from query state and SQL-list syntax; valid author filtering should retain its business result; and both outer-empty and parsed-empty paths should omit the exclusion condition and corresponding writeback. The two additional REST changes present in 6.8.6 are fixed-tree facts; the acceptance record follows the advisory and assigns 6.8 only to CVE-2026-60137.

WordPress 6.9 and 7.0 also need batch-position and dispatch-ownership controls. An in-process fixture can place a preparation error before distinguishable valid members. A fixed build should retain the original response cardinality and keep each error, null placeholder, and valid result in its own position. A white-box harness may additionally compare $matches and $validation indexes for each item. A separate lifecycle control invokes the integration and server entries while an internal dispatch is active; the fixed build should stop at the two new guards, while a paired idle-dispatch control should preserve ordinary top-level service behavior.

The historical template pinned at 9e6cb912c9d4df492b68ac0ecf8c333e2357de06 belongs only in an isolated, explicitly authorized SQLi front-half comparison. An affected 6.9.4 or 7.0.1 baseline is expected to match the complete three-request flow, while 6.9.5 or 7.0.2 is expected not to match. A positive supports time-based blind-SQL-injection reachability under the tested layout. The July 22 false-negative record limits a historical negative: after preserving all three request and response groups, both condition durations, evidence that the third request executed, target artifact, Nuclei and template versions, template digest, operator, time, and network conditions, the negative still records one unmatched run.

The current template should be pinned separately at d51e9a38ae587ccdf7a75fe6aa0e11c81e7d7972 for a route-confusion comparison. An affected baseline is expected to pass the WordPress GET gate and produce HTTP 207, JSON, block_cannot_read, and no rest_term_invalid in the batch POST; the fixed baseline is expected not to satisfy the complete matcher set. A current positive supports route-confusion behavior only, and a current negative records one unmatched run. The SQLi level still requires a historical-template positive or other direct evidence. Preserve the complete GET and POST responses, all four matcher outcomes, target artifact, Nuclei and template ref, operator, time, and network conditions. SOSEC has not executed the local regressions or either detector generation, so both acceptance designs remain "not executed." Every external asset requires explicit authorization before testing.

A passing code-property test describes the artifact under test. Production closure also requires that the same artifact reach every serving unit and that affected replicas, scaling templates, recovery images, and rollback sources leave the deployable set. A current-template positive enters route-confusion investigation; a historical-template positive enters SQLi investigation. Both negatives retain template identity and runtime conditions and stop at one unmatched run. Official version records establish scope, while fixed artifacts and runtime acceptance establish remediation. Version identity, repaired code properties, deployment coverage, and the two detector generations belong in separate fields that meet on the same asset row.

4.2 The complete release, serving units, and rollback sources need one identity

The three maintenance lines deliver the repair cluster through different version-control objects. WordPress 7.0 has three separate branch backports; 6.9 and 6.8 use grouped backports; each fixed tag has its own independent tip. A site operator should acquire the complete maintained release. A downstream distributor that rewrites commit identities needs to supply its base line, a mapping from upstream repairs into local source, immutable build identity, regression evidence, and support path. Copying one visible line from a newer branch loses companion repairs, branch context, and a durable release provenance.

The asset record should separate source or tag identity, acquired package or image, deployment identifier, and running instance. The administration-page version string supports initial location; runtime evidence identifies the code actually loaded by each process. An immutable-image service enumerates active replicas and image digests. A traditional PHP or PHP-FPM service first establishes release-switch behavior, worker lifetime, preloading, and OPcache timestamp policy, then performs only the invalidation, reload, or restart the actual mechanism requires. The pass condition is that every unit capable of accepting a request is tied to a fixed artifact and no affected or unknown unit remains in rotation.

"Cache" covers at least three separate objects in this response. The WordPress object cache stores application objects and query results. PHP OPcache stores compiled program code and can interact with preloading. A CDN stores edge responses. Each layer is handled separately, and a purge result applies only to that layer. Object-cache state helps interpret Cloudflare's attributed condition; OPcache policy helps determine when a replaced file becomes active; an edge purge supports content delivery. Vulnerability closure depends on a fixed core artifact running in the actual service units.

Rollout can move from an isolated copy into a canary and then the remaining pools. Bind each wave to the same digest or immutable image, and record planned and actual instances, start and end times, business regression, REST behavior, query results, application errors, rollback target, and approver. A failed wave stops expansion and keeps a previously accepted fixed build as the rollback destination. If an old image has evidentiary value, isolate it and mark it non-deployable. Updating autoscaling, disaster recovery, snapshots, and provider restore sources extends the fixed release into the next scale-out or recovery event.

5 Close with one finite, reversible ledger

5.1 First hour, rollout, investigation, and retirement share one asset row

The site ledger should be the single authoritative working surface. It orders the first-hour scope decision, temporary control, artifact rollout, runtime acceptance, incident review, exception, and final retirement while retaining two separate conclusions: whether the known software condition has left production, and whether defined evidence sources support exploitation or compromise. An automatic-update notice, WAF dashboard, administration page, or screenshot from one node can become an attachment. No attachment advances the asset to "closed" on its own.

5.2 Remediation and compromise investigation close separately

The remediation track closes when the correct fixed line is established, a trusted artifact covers every request-serving unit, branch-applicable code properties and business behavior pass acceptance, affected content cannot return through rollback, scaling, or recovery, and temporary rules have been retired through a recorded change. Falling scan volume, zero WAF matches, a new version on an administration page, or one negative from either detector generation is a partial observation. Issue #16629 records false negatives in the historical three-request template and closed when PR #16658 supplied the route-confusion replacement on July 24. That change repairs the upstream detection workflow; each site still needs version, artifact, and runtime acceptance. A provider-equivalent backport can close the software track when its source and build identity are auditable.

The incident track closes against its own available data. KEV and both active ADPs support the general finding that both CVEs have known exploitation. Edge access and a WAF action support scanning or an attempt on a specific asset. A current #16658 positive supports route-confusion behavior under its request layout. A complete historical #16596 positive supports blind-SQL-injection reachability. Actual unintended execution on the server supports RCE. Unauthorized data access, execution, or control supports compromise. Both detector negatives stop at one unmatched run; the historical negative also carries its recorded false-negative boundary. The exposure window remains unchanged after either negative. Closure language should name the template generation, reviewed sources, time window, and missing coverage.

The three July 17 WordPress repairs restore three plain rules: an errored subrequest keeps its position in parallel state, an internal subrequest stays inside the dispatch cycle that owns it, and a value entering the author-exclusion SQL list first becomes an integer. WordPress 6.8.6 needs the third property accepted; 6.9.5 and 7.0.2 need all three. The 60137 active/no/total and 63030 active/yes/total ADPs, together with KEV, set current exploitation status and response dates; the WordPress combined RCE finding sets the product consequence; a current #16658 positive sets the route-confusion level; a historical #16596 positive sets the public SQLi front half; issue #16629 limits only the historical negative; and the unverified tail bounds incident conclusions. The resulting actions are deadline or overdue update, serving-artifact verification, generation-specific investigative escalation, unresolved status for both negative types, and finite closure for a specific incident.