CISA's Latest KEV Update Puts WordPress and Langflow at the Front of the Patch Queue
Cloud

CISA's Latest KEV Update Puts WordPress and Langflow at the Front of the Patch Queue

CISA added actively exploited WordPress, Langflow, and DD-WRT flaws to KEV. The exact versions and remediation path are different for each product.

3 min read
Back to News

CISA added four actively exploited flaws to its Known Exploited Vulnerabilities Catalog on July 21. They cover WordPress Core, Langflow, and DD-WRT. The CISA alert makes them an immediate priority, but operators still need product versions and repair details. The response is different for each system.

TL;DR
  • -WordPress 7.0.2 and 6.9.5 fix both listed Core flaws; 6.8.6 fixes the one flaw affecting the 6.8 branch.
  • -Langflow CVE-2026-0770 affects versions through 1.7.3, while the public advisory does not identify a patched version.
  • -DD-WRT builds before 45724 are affected when UPnP is enabled, so teams must verify both build and exposure.

What changed in the KEV catalog

The July 21 update covers:

  • CVE-2026-60137, a WordPress Core SQL injection vulnerability.
  • CVE-2026-63030, a WordPress Core REST API batch-route confusion and SQL injection chain that can lead to remote code execution.
  • CVE-2026-0770, a Langflow validation-endpoint flaw that can allow unauthenticated remote code execution.
  • CVE-2021-27137, a DD-WRT UPnP stack-based buffer overflow.

KEV inclusion means CISA has evidence of exploitation. It does not mean every install is affected or exposed. Match the product and version. Check whether an attacker can reach the vulnerable path. Then apply the supported fix and look for earlier misuse.

The patch decision is different for each product

WordPress: WordPress released 7.0.2 on July 17 and enabled forced updates for affected versions. WordPress 6.9 is affected by both flaws and is fixed in 6.9.5. The 6.8 branch is affected only by CVE-2026-60137 and is fixed in 6.8.6. Versions before 6.8 are not affected.

Check the Core version on production, staging, old campaign sites, and site templates. A plugin inventory cannot answer this Core-version question.

Langflow: The reviewed GitHub advisory for CVE-2026-0770 lists versions through 1.7.3 as affected. It does not identify a patched version. The flaw involves exec_globals in the validation endpoint and needs no login. Do not close the ticket merely because a deployment is newer. Until a supported repair is confirmed, restrict the function and isolate the service. Limit its access to model keys, cloud metadata, databases, and internal APIs.

DD-WRT: NIST says builds before 45724 are affected. Exploitation requires UPnP to be enabled. DD-WRT normally disables it and limits it to internal interfaces. Check the build and settings. Include branch offices, labs, inherited routers, and unmanaged edge devices.

What this means for your operation

The Langflow service may hold credentials used by AI workflows. Attackers have tried to read AWS credentials, environment variables, and container metadata. BleepingComputer says defenders should review validation-endpoint requests, inspect host activity, restrict that function, and rotate credentials when execution cannot be ruled out.

A WordPress breach can become a customer incident. A Langflow breach can expose model providers, data stores, and automation credentials. A router breach can provide a lasting network position. These CVEs belong in one CISA notice, but not in one generic patch ticket.

What to do today

  1. Build three separate asset lists for WordPress Core, Langflow, and DD-WRT. 2. Record the exact version or build, internet exposure, authentication boundary, and downstream credentials for each asset. 3. Apply the verified WordPress releases. For Langflow, follow current vendor guidance and isolate the vulnerable path until remediation is confirmed. For DD-WRT, move to build 45724 or later and verify UPnP exposure. 4. Search logs and endpoint telemetry for activity before the fix.

Treat credential access as an incident, not merely a patching problem. 5. Keep the evidence with the ticket: version proof, exposure decision, remediation, compromise check, and the owner who accepted any remaining risk.

The useful question is not whether the patch system reports green. It is whether the vulnerable path is gone and whether anyone used it while it was open.

Sources and supporting resources
Previous
The AI Half-Hour Test: What Your Company Does With Saved Time Reveals Its Real Strategy
Next
Oracle 26B Expands Contract Manufacturer Visibility for Process Manufacturing

Get Manufacturing Technology Updates

Problem-led guidance on manufacturing operations, integration, portals, analytics, automation, custom software, trusted records, and fit-for-purpose engineering.

No spam. Unsubscribe anytime.