Provenance Record

Well-structured News piece (678 words, within the 400-1200 News range) using an Overview / What We Know / What We Don't Know format. Technical depth is appropriate for a security advisory: the two-CVE chain, the batch-route confusion, and the WP_Query author__not_in SQL injection are each explained and attributed inline. Clear, readable, no filler.

All 5 sources personally verified. (source-0, wordpress.org, HTTP 200 snapshot) confirmed verbatim: '7.0.2 ... addresses one critical and one high severity security issue', 'it is recommended that you update your sites immediately', 'the WordPress.org team have enabled forced updates via the auto-update system for sites running affected versions', the researcher credits ('A facilitated SQL injection issue reported as a team by TF1T, dtro, and haongo' and 'A REST API batch-route confusion and SQL injection issue leading to Remote Code Execution reported by Adam Kues at Assetnote / Searchlight Cyber'), 'Versions of WordPress prior to 6.8 are not affected', 6.9.5 and 6.8.6 fixes, and the CVE references CVE-2026-60137 (SQL injection) and CVE-2026-63030 (REST API/RCE). (source-1, slcyber.io/Searchlight Cyber, HTTP 200 snapshot) confirmed verbatim: 'we are not releasing technical details at this time', 'The best way to protect yourself is to update WordPress to version 7.0.2, or 6.9.5', the WAF mitigation blocking /wp-json/batch/v1 and ?rest_route=/batch/v1, and the wp2shell name/attribution to Adam Kues. (source-3, thehackernews.com, HTTP 200 snapshot) confirmed verbatim: 'wp2shell is two bugs, not one, and both now carry CVE IDs', 'CVE-2026-63030 is the REST API batch-route confusion; CVE-2026-60137 is a SQL injection in WordPress core', the Kues/Assetnote sentence, the /wp-json/batch/v1 parallel-arrays explanation, the WP_Query author__not_in explanation, the exact version breakdown (6.8.0-6.8.5 SQLi only fixed in 6.8.6; 6.9.0-6.9.4 full RCE chain fixed in 6.9.5; 7.0.0-7.0.1 full RCE chain fixed in 7.0.2), the PoC-on-GitHub sentence, the CISA KEV sentence ('not on CISA's KEV catalog ... none has been reported as of July 18'), the 'reported separately by TF1T, dtro, and haongo' line, and critically the severity divergence: 'WordPress's own advisory rates the RCE chain Critical. Its CVE record scores it 7.5, only High.' (source-4, helpnetsecurity.com, HTTP 200 snapshot) confirmed verbatim the workaround caution: 'may have impact on legitimate use of the site and should only be considered emergency temporary measures until you can update'. (source-2, bleepingcomputer.com) the automated snapshot FAILED with HTTP 403 (bot-blocked, file null in manifest); per skill fallback I WebFetched the live URL and confirmed verbatim all three claims attributed to it: the CVE-2026-63030/CVE-2026-60137 chain sentence against 6.9.x and 7.0.x, 'Searchlight Cyber estimates that more than 500 million websites use WordPress ...', and watchTowr's 'we are beginning to see the first signs of in-the-wild exploitation'.

All security specifics verified. CVE mapping is correct and internally consistent across sources: CVE-2026-63030 = REST API batch-route confusion/RCE, CVE-2026-60137 = SQL injection (confirmed by both The Hacker News's explicit statement and WordPress.org's ordered CVE/credit list). CVSS score 7.5 (rated High on the CVE record while WordPress's advisory rates the chain Critical) is accurately attributed to The Hacker News and correctly framed as a divergence rather than presented as a single authoritative rating. Version numbers (7.0.2, 6.9.5, 6.8.6, affected branches 6.8.0-6.8.5 / 6.9.0-6.9.4 / 7.0.0-7.0.1) all match sources. Release date July 17 confirmed. No hallucinated quotes; several quotes are legitimately truncated (ended mid-sentence with a closing period) without altering meaning.

High-quality, accurate, and well-sourced security report. Every direct quote is verbatim from its cited source, every CVE/CVSS/version/name specific traces to a source, and the headline, summary, and lead are each backed. The two automated warnings are archival/allowlist matters with no reader-facing consequence, so APPROVE (not APPROVE_WITH_CORRECTIONS) is the correct verdict. Ready for publication.