Skip to main content
Change Risk Intel
Cybersecurity

CISA's July 21 KEV Batch: How a CAB Should Triage 4 CVEs

Ben Ennis · 12 min read

Why this matters right now

On July 21, 2026, CISA added four vulnerabilities to its Known Exploited Vulnerabilities catalog in a single batch: two WordPress core flaws, a Langflow remote-code-execution bug, and an aging DD-WRT router defect. The batch is awkward for exactly the reason it is instructive — it spans a content management system, an AI-workflow platform, and consumer-grade edge hardware, three asset classes that almost never share a change window, an owner, or a patch tool.

For a Change Advisory Board, that spread is the whole problem. A batch like this arrives with mismatched deadlines and mismatched blast radii, and the temptation is to triage each CVE the way the ticket queue happens to surface it. That is how the shortest deadline gets missed. Two of these four carry a federal remediation due date of July 24, 2026 — three days after listing — per the NVD record for CVE-2026-63030. This piece lays out how to rank the batch, what each flaw actually does, and how the new BOD 26-04 risk-based model changes the triage math versus the old KEV playbook. For more analysis in this vein, see our full cybersecurity coverage.

What CISA added on July 21

Here is the batch, ranked by remediation urgency rather than the order CISA listed them. Due dates are from the NVD KEV metadata; the exploit descriptions are from each CVE’s NVD record and vendor advisory.

CVEProductFlawDue date (FCEB)Why it ranks here
CVE-2026-63030WordPress coreREST API batch-route confusion2026-07-24Chains with 60137 to unauth RCE; 3-day clock
CVE-2026-0770Langflowexec_globals unauth RCE as root2026-07-24Unauthenticated code execution as root
CVE-2026-60137WordPress coreauthor__not_in SQL injection2026-08-04Injection half of the RCE chain
CVE-2021-27137DD-WRTUPnP/SSDP buffer overflowSee KEV entryLegacy edge device; hardest to inventory

The single most important line in that table is that the two July 24 entries chain together. NVD describes CVE-2026-63030 as a “REST API batch endpoint route confusion issue which, combined with the author__not_in WP_Query SQL Injection (CVE-2026-60137), could allow an attacker to perform SQL Injection and achieve Remote Code Execution,” per the NVD entry for CVE-2026-63030. Triaged separately, one looks like a routing quirk and the other like a plugin-dependent SQL bug. Triaged together, they are an unauthenticated path to code execution on any exposed WordPress core install — the combination researchers have been calling “wp2shell,” which had a working public proof-of-concept before it hit KEV, per a 0dayNews week-in-review briefing.

The WordPress chain: two CVEs, one exploit path

WordPress shipped emergency fixes on July 17, 2026, ahead of the KEV listing. Per the official WordPress 7.0.2 release note, the SQL injection issue (CVE-2026-60137) was reported by a team credited as TF1T, dtro, and haongo, and the route-confusion-to-RCE issue (CVE-2026-63030) was reported by Adam Kues at Assetnote / Searchlight Cyber. The release note is unusually direct about the chain: WordPress 6.9 is affected by both flaws and 6.9.5 fixes both; WordPress 6.8 is affected only by the SQL injection and 6.8.6 addresses it; the 7.1 beta line is affected by both and 7.1 beta2 carries both fixes. Versions prior to 6.8 are not affected.

That version matrix matters for a CAB because it dictates how many distinct change records you need. A shop running a single WordPress version needs one change. A shop running 6.8 marketing sites and 6.9 application blogs needs two, on two different due dates — 6.8 sites are exposed only to the August 4 SQL injection, while 6.9/7.0 sites carry the July 24 RCE chain. Mapping which of your sites sits on which branch is the pre-read work; NVD lists the affected ranges as “WordPress 6.9.x before 6.9.5 and 7.0.x before 7.0.2” for the route-confusion flaw and adds “6.8.x before 6.8.6” for the injection, per the NVD entry for CVE-2026-60137.

The change-management lesson here generalizes past WordPress. Interpretation-conflict flaws — where two components each enforce reasonable-looking rules but disagree on how to parse a request — show up in API gateways, reverse proxies, and identity systems, not just CMS cores. If your CAB treats “route confusion” as a WordPress-only category, it will miss the next one. This is the same monitoring discipline covered in our guide to the external risk sources every CAB should monitor.

The Langflow flaw: shadow AI as a change-management gap

CVE-2026-0770 is the entry most likely to be missing from your asset inventory entirely. NVD describes it as a “Langflow exec_globals Inclusion of Functionality from Untrusted Control Sphere Remote Code Execution Vulnerability” where “authentication is not required to exploit,” the flaw “exists within the handling of the exec_globals parameter provided to the validate endpoint,” and an attacker can “execute code in the context of root,” per the NVD entry for CVE-2026-0770. It originated as Zero Day Initiative advisory ZDI-26-036.

Langflow is a platform teams use to build and run AI-driven workflows, and that is precisely why it is a change-management blind spot. These instances are frequently stood up by developers or data-science teams as proofs of concept, outside any formal provisioning process — the definition of shadow IT, now wearing an AI badge. An unauthenticated root RCE on a service that data teams point at internal databases and API keys is a credential-exposure event, not just a patch. The CAB triage step is unusual: the first question is not “which version do we run” but “do we run this at all, and does anyone know where.” If the answer is uncertain, the compensating control — remove public exposure, force access through a VPN or authenticated reverse proxy, and rotate any credentials the service could reach — has to land before the patch, because you cannot patch an instance you have not found.

The DD-WRT flaw: the unpatchable edge case

CVE-2021-27137 is the outlier: a five-year-old stack-based buffer overflow in the UPnP service of certain DD-WRT router firmware builds, reachable through crafted SSDP M-SEARCH traffic on UDP port 1900, per CISA’s KEV entry and corroborating analysis from WindowsForum. Its presence in a 2026 batch is a reminder that KEV is an exploitation signal, not a freshness signal — an old CVE lands here because someone is using it now.

For a CAB, the DD-WRT entry is the classic unpatchable-asset problem. DD-WRT is community firmware often running on hardware the organization no longer formally tracks. The triage is a lifecycle decision, not a patch decision: identify deployments, establish firmware build numbers, disable UPnP where it is not operationally required, ensure the management interface is not internet-exposed, and — if the hardware cannot reach a fixed build — put replacement on the risk register with a hard deadline rather than filing a permanent exception. An indefinite exception is how a KEV entry quietly becomes a breach three years later.

How BOD 26-04 changes the triage math

The old KEV playbook, under BOD 22-01, was simple: KEV membership meant patch by the due date, full stop. BOD 26-04, issued in June 2026, layers a risk-based model on top of that. Rather than replacing KEV, the directive “makes KEV information more actionable by combining it with operational factors that better reflect real-world risk,” according to an analysis of BOD 26-04 by Invicti. In practice, the KEV requiredAction field on these July entries now points agencies at BOD 26-04 guidance for prioritization rather than a flat “patch it” instruction.

For change managers — federal or not — the shift is worth internalizing. A risk-based directive rewards CABs that can answer, quickly, five questions about any KEV entry: what is exposed, who owns it, whether it is actively exploited, what it can reach, and whether an attacker may already be inside. The July 21 batch is a live drill for exactly that capability. The WordPress chain scores high on “what it can reach” for any site handling payments or customer data; the Langflow flaw scores high on “what it can reach” because of stored credentials; the DD-WRT flaw scores high on “who owns it” precisely because the answer is usually nobody. A CAB that ranks the batch on those axes will land on the same ordering as the due dates — which is the point of a well-calibrated risk model. For teams still building this muscle, our guide to reading a CISA KEV entry breaks down the ten fields that feed this triage, and the CAB meeting playbook covers how to slot emergency items into a standing agenda.

A same-day CAB pre-read for this batch

Structure the pre-read so reviewers can rank all four in under five minutes:

  1. Header line per CVE: CVE ID, product, due date, and exploit path (chain / standalone RCE / injection / legacy) — before any prose.
  2. Blast radius: WordPress version census across all sites; a yes/no/unknown on whether Langflow exists anywhere; a count of DD-WRT devices from network discovery, not the CMDB alone.
  3. Change class per CVE: emergency for the two July 24 RCE paths, expedited for the August 4 SQL injection, lifecycle-decision for DD-WRT.
  4. Compensating control if the patch cannot land in time: WAF rules and version verification for WordPress; remove-public-exposure plus credential rotation for Langflow; disable UPnP and restrict management access for DD-WRT.
  5. Rollback plan: one line each. For WordPress, confirm clean backups before the emergency change, not after.

Run this against a live Patch Tuesday calendar so KEV-driven emergency changes are deconflicted with scheduled vendor releases rather than colliding with them.

What to do about it

  1. Verify deployed versions rather than assuming auto-updates ran. Upgrade WordPress 6.9 sites to 6.9.5, 7.0 sites to 7.0.2, and 6.8 sites to 6.8.6, per the WordPress 7.0.2 release note.
  2. Hunt for Langflow before you patch it. Query network discovery and cloud inventory for the service; if any instance is internet-facing, remove exposure and rotate reachable credentials today.
  3. Treat the two July 24 entries as one emergency change window, not two tickets, since they share a deadline and the WordPress pair chains together.
  4. Route CVE-2026-60137 to an expedited change tied to its August 4 due date, and confirm which sites are on the 6.8 branch — they are exposed only to this flaw.
  5. Make the DD-WRT entry a lifecycle line item: disable UPnP, confirm no internet-exposed management interface, and register hardware replacement with a dated deadline if no fixed build exists.
  6. Review WordPress web logs for anomalous REST API batch requests and suspicious POST bursts around the July 17 disclosure window before closing the change.
  7. Adopt the KEV due dates as internal SLAs even if you are not an FCEB agency; cyber-insurance underwriters increasingly treat KEV membership as a patch-now signal regardless of directive scope.
  8. Score every KEV entry against the five BOD 26-04 questions — exposed, owned, exploited, reachable, breached — so your ranking survives the next mismatched batch.

Frequently asked questions

Which July 21 KEV CVEs have the shortest deadline? CVE-2026-63030 (WordPress route confusion) and CVE-2026-0770 (Langflow RCE) both carry a federal due date of July 24, 2026 — three days after listing. CVE-2026-60137 is due August 4, 2026.

Why triage CVE-2026-63030 and CVE-2026-60137 together? NVD states the two combine: the route-confusion issue paired with the author__not_in SQL injection can allow an unauthenticated attacker to reach remote code execution. Chained, they are a full compromise path.

What makes Langflow CVE-2026-0770 a change-management blind spot? It is an unauthenticated RCE as root on an AI-workflow platform teams often deploy outside formal IT provisioning, so discovery precedes patching.

Do CISA KEV due dates apply to private companies? No — they bind only FCEB agencies, though many firms adopt them as internal SLAs and insurers treat KEV membership as a patch-now signal.

How does BOD 26-04 change KEV remediation? It adds a risk-based model on top of KEV, weighing exposure, ownership, exploitation, reachability, and possible compromise instead of a flat due-date rule.

Why is a 2021 DD-WRT CVE in a 2026 batch? KEV signals active exploitation, not novelty. For unpatchable community firmware, the fix is a lifecycle decision, not a patch.

Sources

#cisa-kev #vulnerability-management #cybersecurity #wordpress #bod-26-04

Published July 22, 2026.