📢 New post: The Same Door, Three Times: Langflow CVE-2026-0770 and a Clock That Already Ran Out · 📝 Also fresh: The Same Appliance, Twice: FortiSandbox CVE-2026-25089 and the Boundary You Don't Operate · 🚦 Beacon — the FedRAMP 20x KSI emitter — design partners open ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
AI SecurityFedRAMPConMonCISA

The Same Door, Three Times: Langflow CVE-2026-0770 and a Clock That Already Ran Out

Two weeks ago we wrote about Langflow on the KEV catalog for an authorization bypass — one tenant executing another tenant's flows. Six weeks before that, an account-takeover-to-RCE chain. We noted at the time that two entries in six weeks was worth pausing on.

On July 21, CISA added CVE-2026-0770 — Langflow again. The federal remediation deadline was July 24, three days out.

That was Friday. It's Monday. If you're reading this looking for a head start, you don't have one, and it's worth being honest about that up front rather than writing as though the clock is still running.

What the catalog actually says

The KEV entry is Langflow Inclusion of Functionality from Untrusted Control Sphere Vulnerability — CWE-829 — described as allowing remote attackers to execute arbitrary code on affected installations. The Zero Day Initiative advisory that carries the technical detail (ZDI-26-036, ZDI-CAN-27325) is more specific: the flaw is in how Langflow handles the exec_globals parameter at the validate endpoint, and exploitation requires no authentication and yields code execution with root privileges.

ZDI, acting as CNA, scores it 9.8 with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. NVD's own CVSS v4.0 analysis is still listed as awaiting analysis, so treat 9.8 as the operative number for now and expect it to be confirmed rather than moved — there isn't much room above it.

Unauthenticated, network-reachable, no user interaction, root. That's about as clean a shape as a vulnerability gets, and it's why the due date was three days instead of fourteen.

The part that isn't new

Here's what makes this one worth a post rather than a line in a bulletin.

Pull the KEV catalog and filter for Langflow and you get five entries:

  • CVE-2025-3248 (added May 2025) — missing authentication on /api/v1/validate/code, unauthenticated RCE.
  • CVE-2026-33017 (added March 2026) — code injection, flows buildable without authentication.
  • CVE-2025-34291 (added May 2026) — permissive CORS plus a SameSite=None refresh cookie, chained into code execution.
  • CVE-2026-55255 (added July 2026) — authorization bypass, one user executing another's flows.
  • CVE-2026-0770 (added July 2026) — exec_globals at the validate endpoint, unauthenticated RCE as root.

Three of those five — the first, the third, and this one — terminate at the same place: the endpoint whose job is to validate and run user-supplied Python. CVE-2025-3248 got there because nothing was checking authentication. CVE-2025-34291 got there by stealing a token first. CVE-2026-0770 gets there through a parameter that was never supposed to be attacker-influenced.

Different bugs. Same door.

That's not a criticism of a maintainer's patch quality, and we'd rather not frame it that way. It's a structural observation, and it's the useful one: Langflow's core feature is executing code you hand it. Every fix so far has been another lock on a door that opens into the interpreter by design. Locks are good. But if you're doing threat modeling rather than patch management, the thing to model isn't "Langflow has vulnerabilities" — it's "Langflow has an intentional code-execution surface, and the access control in front of it has failed under three separate conditions in fourteen months."

That reframes what remediation means. Patching closes this path. It does not change the fact that a reachable code-execution endpoint is the product's architecture.

Six months in the open

The disclosure timeline in the ZDI advisory is the other thing worth sitting with:

  • 2025-07-18 — vendor notified.
  • 2025-09-11 — status inquiry.
  • 2025-10-10 — fix requested.
  • 2025-12-10 — 0-day publication notice.
  • 2026-01-09 — advisory published publicly, unfixed.
  • 2026-01-22 — NVD publication.
  • 2026-07-21 — KEV listing, three-day clock.

The mitigation ZDI could offer when it published was, in their words, that "the only salient mitigation strategy is to restrict interaction with the product." Not a version to upgrade to. Restrict access to it.

So the honest compliance question here isn't "did you patch inside three days." It's: an unauthenticated root RCE in an AI platform was public and unpatched from January 9 to July 21 — what was your program doing with it during those six months? For most environments the answer is "nothing, because it wasn't on KEV yet, so it wasn't on the clock." That's exactly the reflex BOD 26-04 was written to retire. Exposed, automatable, grants full control — three of the four risk questions were answerable yes in January. The fourth one, active exploitation, is the only thing that changed in July, and it's the one you have the least control over knowing.

The version guidance is genuinely muddy — plan around that

This part we'd normally skip, but it changes what you should actually do.

  • NVD lists affected versions as up to and including 1.7.3.
  • CISA's KEV notes point to the v1.9.0 release as the remediation reference.
  • That v1.9.0 changelog does not name CVE-2026-0770, exec_globals, or the validate endpoint — it lists a set of other security fixes (a build_public_tmp RCE, an MCP command-injection allowlist, a build_flow ownership check, a path-traversal write).
  • And our last Langflow post put the fix for CVE-2026-55255 in 1.9.1, while the KEV notes for CVE-2025-34291 point at v1.9.3.

We're not going to resolve that from the outside, and we'd rather say so than publish a version number we can't stand behind. What it means practically:

  • Don't close the finding on a version string alone. "We're on 1.9.x" is not evidence that this specific path is closed when no changelog entry claims it.
  • Get it in writing from the vendor if you need the finding closed for an assessment. A maintainer confirmation naming the CVE is worth more than an inferred release tag.
  • Take ZDI's mitigation seriously as a control in its own right. Restricting who can reach the validate endpoint — network policy, authenticating reverse proxy, no internet exposure — is defensible, documentable, and doesn't depend on the version question resolving.

If you're inside a FedRAMP boundary

The KEV-clock mechanics are the ones we've walked several times now, so we won't relitigate them — a catalog entry inherits its federal due date and that date overrides the comfortable 30/90/180-day continuous-monitoring windows. What's specific to this one:

  • All four BOD 26-04 lights are red. Publicly exposable, fully automatable (unauthenticated single-request RCE is the definition), grants complete control (root), actively exploited (that's what the KEV listing asserts). That's the top urgency band — three days, plus forensic triage — and CISA's required-action text for this entry names the Forensics Triage Requirements explicitly. This is not a "patch and close it" item. The directive is asking you to determine whether it was already used against you.
  • Treat the host as suspect, not just outdated. Root-level RCE on an orchestration platform means every credential that platform held — model API keys, vector store access, database passwords, service tokens — is a rotation candidate. We made this point in May and it applies harder here, because root plus no authentication means there's no session to correlate against a user.
  • The deadline passed — document the deviation properly. Missing a KEV due date isn't fatal; failing to record it is. Open the POA&M with the actual dates, the reason, the compensating control you put in place, and the target. An assessor who finds a documented late remediation with a mitigation in the gap is in a very different conversation than one who finds silence.
  • The evidence trail is still the durable artifact. Version before and after, the access-restriction change and when it landed, the log review for requests to the validate endpoint, the rotation tickets. Same as ever.

What we keep coming back to

Five KEV entries for one product in fourteen months is a signal about the product, but it's a bigger signal about how these platforms enter an environment. Nobody procures Langflow through a review board. Someone stands it up to prototype, it works, it accumulates credentials and traffic, and it never gets reclassified from "experiment" to "production system with a root-capable code-execution endpoint." By the time it's on a three-day clock, the hard part isn't patching — it's finding out you have it.

So the question this one leaves us with is narrower than usual, and it's not really about Langflow: for the AI tooling inside your boundary, do you know which of it executes code you supply — and is that surface reachable by anyone who hasn't authenticated? If you can answer that from an inventory query rather than a Slack thread, the next entry on this catalog is an afternoon. If you can't, it's a week you didn't have.

That's the shape of work we've been building the Novaprospect audit engine toward — infrastructure-native discovery that surfaces the system nobody wrote down, and evidence collected as a normal byproduct, so that when a three-day clock starts on a Friday you're checking a record instead of starting an investigation.

Reference