🤝 Open to acquisition: what is built, what runs, and what a buyer inherits · 📉 Corrections record: AI mistakes, counted by class and fed back into the next run · 📢 New post: Same Software, New Nameplate: Langflow's Sixth KEV Entry Arrives Under a Different Vendor · 📝 Also fresh: The Sibling You Didn't Patch: ownCloud CVE-2023-49105 and a Clock That Started 1,010 Days Late · 🚦 Beacon — the FedRAMP 20x KSI emitter — see what it emits ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
AI SecurityFedRAMPConMonCISA

Same Software, New Nameplate: Langflow's Sixth KEV Entry Arrives Under a Different Vendor

We have written about Langflow on this catalog three times before, most recently in July, when we counted five KEV entries in fourteen months and said the useful question was whether you could find the thing in an inventory query rather than a Slack thread.

On August 4, CISA added CVE-2026-9198. Federal remediation deadline: August 7. That was three weeks ago, so let's be straight about it — if you came here for a head start, there isn't one, and the work in front of you is reconstruction rather than response.

The vulnerability itself is a clean unauthenticated RCE and we'll walk it below. But it isn't the reason this one earned a post. The reason is a single field in the catalog row.

The field that changed

Pull the KEV feed and filter it for Langflow. Here is what the vendor column says, in order:

Added vendorProject CVE
2025-05-05 Langflow CVE-2025-3248
2026-03-25 Langflow CVE-2026-33017
2026-05-21 Langflow CVE-2025-34291
2026-07-07 Langflow CVE-2026-55255
2026-07-21 Langflow CVE-2026-0770
2026-08-04 IBM CVE-2026-9198

The CVE was assigned and scored by IBM's PSIRT (psirt@us.ibm.com). The advisory lives on ibm.com. The KEV entry is titled IBM Langflow Code Injection Vulnerability, and the affected-product string IBM supplied to NVD reads "Langflow OSS 1.0.0 through 1.10.0."

The software is the same software. The fix is 1.10.1, cut from langflow-ai/langflow on June 23 — the same public repository that shipped every prior fix, still active and now on a 1.11.x line. Nothing moved on your host or in your requirements.txt. What moved was the label on the record.

Why the nameplate changed is IBM's business and the catalog doesn't explain it. What matters here is narrower and entirely practical: your automation joins on these strings, and it does not know that.

Three matchers, two misses

This is worth being concrete about, because "keep your inventory current" is advice nobody can act on, and "check which key your matcher joins on" is something you can go do this afternoon.

The KEV vendor string — misses. A watcher that pulls the catalog daily and filters vendorProject == "Langflow" matched every entry from May 2025 through July 2026 and then silently stopped. Not an error — just a row that no longer meets the predicate, in a feed where the absence of a match is the normal case. If your Langflow alerting is built that way, August 4 came and went and the pipeline reported that everything was fine.

The dependency advisory — misses, for a different reason. Every one of the five prior Langflow KEV CVEs has a reviewed GitHub advisory carrying a real package coordinate: pip/langflow, with a vulnerable range and a patched version. CVE-2026-9198's advisory (GHSA-5wm9-vgmg-cjv6) is unreviewed — auto-ingested from NVD — and its affected-package list is empty. No package name, no version range.

An advisory with no package coordinate cannot match a dependency graph. Dependabot and the SCA tooling downstream of that data have nothing to join against, so a scanner that flagged you for CVE-2026-0770 in July stayed quiet for the more severe bug in August. The advisory exists; it just isn't wearing anything your scanner can grab. We nearly got this wrong ourselves — querying GitHub's advisory API filtered by affected package returns no result for this CVE, which looks exactly like "no advisory was published." Asking for it by CVE ID directly returns it immediately.

The CPE — holds. NVD's analysts did their applicability mapping and produced cpe:2.3:a:langflow:langflow, version 1.0.0 up to but excluding 1.10.1. Not ibm:langflow_oss — which is what IBM's own CNA submission carries — but the same langflow:langflow identifier that matched all five earlier entries.

So the join key that survived a vendor change is the one derived from the software rather than from whoever filed the paperwork. That's the takeaway with a shelf life longer than this CVE: prose fields in a vulnerability feed are editorial, and CPEs are the closest thing to a stable identity the ecosystem offers. If your KEV process pattern-matches on product names because it was quicker to build, this is the entry that shows you the bill.

What actually broke

IBM's bulletin titles it Unauthenticated Remote Code Execution via Auto-Login Bypass and Code Validation, and the chain is two links:

  1. /api/v1/auto_login issues a SUPERUSER bearer token to any caller who can reach it over the network. No credential is presented, because the endpoint's purpose is to not require one.
  2. /api/v1/validate/code executes user-supplied Python through exec(). Per IBM's writeup, the validator evaluates decorators, default arguments, and annotations at function-definition time — so merely defining a function is enough to run commands on the host.

Get a superuser token from the first, post code to the second. It's CWE-94, and it works on any default deployment where auto-login is enabled and the validation endpoint is reachable. IBM scores it 9.8 critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Worth stating precisely, since we've been burned by the distinction before: that 9.8 is IBM's score, carried in NVD as a secondary metric. NVD analyzed the record — it produced the CPE mapping above — but published no CVSS of its own. There is no NIST number here, so cite it as IBM's. Nothing in the vector looks arguable, but "NVD rates it 9.8" would be a sentence you couldn't support.

IBM lists workarounds and mitigations as none. Upgrade is the entire remediation path.

The detection you already wrote doesn't fire

Here's the operational sting, and it's specific to how this chain is shaped.

/api/v1/validate/code is not a new address. It's the endpoint behind CVE-2025-3248, Langflow's first KEV entry back in May 2025 — a missing-authentication bug, and the only Langflow entry CISA marks with known ransomware campaign use. If you responded to that one properly, you very likely came away with a detection rule, and it very likely says something close to alert on unauthenticated requests to the code-validation endpoint.

That rule does not fire on CVE-2026-9198. The request to /api/v1/validate/code in this chain is authenticated. It carries a valid SUPERUSER bearer token that the application minted, on request, exactly as designed. Nothing about it is malformed, and the privilege check passes because the privilege is real.

Which means the anomaly isn't at the endpoint you're watching. It's one step earlier, at the token grant: a SUPERUSER credential issued to a caller who never presented one. When you go looking, that's the log line — calls to /api/v1/auto_login, and what the resulting tokens went on to do — and it will not be in whatever query you built for last year's bug. Code execution leaves something out of place; a legitimately-issued token leaves a well-formed, correctly-attributed request. You're hunting misplaced trust, not intrusion.

The clock, honestly

Assembling every date the records carry:

  • June 23 — Langflow 1.10.1 ships publicly. The fix is available.
  • July 2 — IBM publishes the security bulletin (per its own change history).
  • July 17 — the CVE publishes. The same day, CISA's SSVC record scores it exploitation: active, automatable: yes, technicalImpact: total.
  • August 4 — KEV listing.
  • August 7 — federal due date.

Two gaps are worth sitting with. The fix was public for 42 days before the catalog entry created an obligation to apply it. And CISA's own record says exploitation was active on July 17 — eighteen days before the listing that put it on your radar.

That second one is not a complaint about CISA's turnaround; it's a boundary condition for your forensic triage. If you scope a log review to the KEV date, you are looking at the wrong window by more than two weeks, and by six weeks against the date an unpatched instance became a known-fixable liability. The left edge of the investigation is July 17 at the latest. Given the bug needs one reachable endpoint and no credential, June 23 is the more defensible place to start.

If you're inside a FedRAMP boundary

The KEV-clock mechanics we've walked several times, so briefly: the catalog entry inherits a federal due date that overrides your comfortable 30/90/180-day continuous-monitoring windows, and under BOD 26-04 the triage questions are about exposure, automatability, control, and exploitation rather than the CVSS number. This entry answers yes across the board, and CISA's required-action text names the Forensics Triage Requirements explicitly — so it is not a patch-and-close item.

What's specific to this one:

  • Check whether you're patched under both names. Your inventory says Langflow. The catalog says IBM. Whatever you query — CMDB, SBOM, container manifests — confirm the query would have caught this row, and fix the query if it wouldn't. That finding is more durable than the patch.
  • Treat the deadline miss as documentation work. Three weeks past due isn't fatal; unrecorded is. The POA&M wants the real dates, the reason it was missed, whatever compensating control sat in the gap, and a target. An assessor reading a documented late remediation is in a different conversation than one reading silence.
  • Rotate anything the platform held. Superuser-level code execution on an orchestration host means the model API keys, vector store access, and database credentials that platform holds are all rotation candidates. We said this in May and it hasn't stopped being true.
  • Scope the review from July 17, not August 4 — and query auto_login, not just the validate endpoint.
  • 1.10.1 closes it; 1.11.x is where the project lives now. Pin deliberately rather than landing on the minimum version that clears the finding.

What this one leaves us with

The throughline in this series has been know what you run before someone asks you under a clock. This entry sharpens it in a way we didn't expect: knowing what you run isn't enough if the catalog and your inventory have quietly stopped calling it the same thing.

That's the shape of work the Novaprospect audit engine keeps aiming at — identity resolved from what's actually deployed rather than from a name somebody typed into a spreadsheet, with evidence accumulating as a byproduct rather than as an archaeology project started the week after a deadline.

So the question to carry into the next one: when a vendor field changes on a product you already run, what in your pipeline notices? If the answer is a person who happened to read the catalog that morning, that person is your control — and they were on leave the week of August 4.

Reference