Langflow's Second Critical CVE in a Year: What CVE-2026-55255 Means If You're Still Running It

Five days ago we covered JADEPUFFER, the autonomous-agent ransomware attack that exploited CVE-2025-3248 in Langflow, the open-source AI workflow builder, and pushed Anthropic to make Claude Code's permission mode manual-by-default. This week Langflow disclosed a second critical vulnerability, CVE-2026-55255 — an IDOR/authorization-bypass flaw rated CVSS 9.9 — and CISA added it to the Known Exploited Vulnerabilities catalog on July 7, with in-the-wild exploitation dating back to June 25. That's a different CVE, a different bug class, and a different disclosure timeline than JADEPUFFER's CVE-2025-3248 — but the same tool, twice, inside about a year. If Langflow is anywhere in your agent stack — as a workflow builder, a prototyping layer, or something a teammate spun up and half-forgot about — this is the point where 'unpatched dependency' stops being a hypothetical line item in a security checklist and starts being an active exposure with a KEV listing attached to it.

What You'll Learn

What an IDOR/authorization-bypass vulnerability actually lets an attacker do versus the remote-code-execution class that JADEPUFFER exploited; why a CISA KEV listing changes the urgency calculus differently than a plain CVE score does; how to tell whether this is 'a Langflow problem' or a pattern you should expect from any AI-workflow-builder category; and a concrete checklist for auditing whether Langflow (or a tool like it) is running somewhere in your stack right now, unpatched, and reachable.

Step 1: Know the Bug Class — IDOR/Authz Bypass, Not RCE

CVE-2025-3248, the flaw JADEPUFFER used, was a remote-code-execution bug: attacker-supplied input got executed as code. CVE-2026-55255 is different — an Insecure Direct Object Reference (IDOR) combined with an authorization bypass. In practice that means the flaw isn't about tricking Langflow into running attacker code; it's about Langflow failing to check whether the requester is actually allowed to access a given object (a flow, a credential store, a project) before serving it. The practical effect can still be severe — credential and data exposure, unauthorized flow modification, account takeover — which is why it still lands at CVSS 9.9, but the exploitation path is 'ask for something you shouldn't have access to and get it anyway,' not 'inject a payload that runs.'

Step 2: Understand Why the KEV Listing Matters More Than the CVSS Score

A 9.9 CVSS score tells you the theoretical severity. CISA's Known Exploited Vulnerabilities catalog tells you it's not theoretical — federal agencies are required to patch KEV-listed flaws within a mandated window because active exploitation is already confirmed, not projected. CVE-2026-55255 was added to KEV on July 7, with exploitation traced back to June 25 — meaning there was roughly a two-week gap between attackers actively using this bug and it landing on the list most security teams treat as their patch-priority signal. If your vulnerability-management process waits for a KEV listing to trigger action, you were already exposed for two weeks before the trigger fired.

Step 3: Read the Pattern, Not Just the Individual CVE

One critical CVE in an open-source tool is a bug. A second unrelated critical CVE in the same tool within about a year, in a different vulnerability class, is a pattern worth updating your risk model over. It doesn't mean Langflow is uniquely poorly built — AI workflow builders are a young, fast-moving category, and the JADEPUFFER writeup and CyberOS's own scanning data both point to Langflow simply being widely deployed enough that its flaws get found and exploited, rather than it being categorically worse than comparable tools. The actionable takeaway is about the category, not just this one project: if a tool in your stack orchestrates agent workflows and touches credentials, treat 'AI workflow builder' as a class that warrants the same patch-cadence discipline you'd apply to a database or an auth provider, not a hobby-project weekend install.

Step 4: Audit Your Own Exposure

Check three things today. First, inventory: do you, or does anyone on your team, have a Langflow instance running anywhere — a demo environment, a prototype, a forgotten Docker container from a hackathon six months ago? Second, version: is it patched against CVE-2026-55255, and separately, was it ever patched against CVE-2025-3248? Both matter independently. Third, exposure: is the instance reachable from the public internet, or gated behind a VPN/auth layer that would blunt an IDOR bypass's usefulness to an outside attacker? An internet-facing, unpatched Langflow instance with real credentials wired into its flows is the exact configuration both CVEs turn from 'a bug' into 'an incident.'

Common Challenges

"We only used Langflow for a demo, it's not really 'in production'" — That's precisely the exposure JADEPUFFER and CVE-2026-55255 both prey on: demo and prototype instances get spun up quickly, get real API keys and credentials wired in for the demo to actually work, and then don't get the same patch discipline as production infrastructure because nobody thinks of them as production. "IDOR sounds less scary than RCE, do we need to treat this with the same urgency?" — Yes. CVSS 9.9 reflects real-world impact, not just exploit sophistication — an authorization bypass that exposes credentials or lets an attacker modify agent workflows can be just as damaging as code execution, and it's often easier to exploit at scale because it doesn't require crafting a working payload. "How do we know if we've already been hit?" — Check access logs on any Langflow instance for requests to object IDs or resources the requesting session shouldn't have had access to, and rotate any credentials that were reachable through the affected instance regardless of whether you find direct evidence — with exploitation confirmed back to June 25, absence of evidence in incomplete logs isn't evidence of absence.

Advanced Tips

Don't let a KEV listing be your only patch trigger. Build a lighter-weight internal signal — a subscription to your dependencies' security advisories, or a scheduled dependency-CVE scan — that fires faster than the two-to-three-week lag between real-world exploitation and KEV inclusion this incident demonstrated. Separate demo/prototype credentials from production ones categorically. If a Langflow (or similar) instance only needs read access to a sandbox dataset to do its demo job, it should never hold a credential capable of touching production data — that scoping discipline is what limits the blast radius when the next CVE in this category lands. Treat 'second CVE in the same tool' as a trigger for a fuller audit, not just a patch. When any tool in your stack has now had two critical, actively-exploited CVEs, that's the moment to ask whether it's still the right tool for the job, not just whether this specific patch is applied — the same logic CyberOS applies when scanning a codebase for AI-agent tooling with a recurring vulnerability history.

Conclusion

CVE-2026-55255 isn't JADEPUFFER's sequel in the sense of reusing the same bug — it's a different flaw entirely, an IDOR/authorization bypass rather than remote code execution — but it lands in the same tool, with the same lesson: unpatched AI-agent infrastructure is an active target, not a background risk. The two-week gap between confirmed exploitation and CISA's KEV listing is the detail worth internalizing regardless of which specific tool you run — waiting for an official severity signal means you're patching after the fact, not ahead of it. If Langflow or a comparable AI workflow builder is anywhere in your stack, this week is the week to check its version and its blast radius, not the week to file this under 'read later.' For the full incident history and defensive posture around agent permission scoping, see our earlier piece on JADEPUFFER and Claude Code's manual permission mode, and Chapter 10 of the Vibe Coding Ebook (The Dark Side) for the broader pattern of unpatched dependencies in agentic AI incidents. For continuous scanning of AI-generated codebases and agent configurations against exactly this class of flaw, see CyberOS. For daily coverage of stories like this as they break, subscribe to the EndOfCoding newsletter.