On 7 July 2026, CISA added CVE-2026-55255 to its Known Exploited Vulnerabilities (KEV) catalogue and ordered US federal agencies to fix it by 10 July. The urgency is routine; what makes this one worth your attention is what was being stolen through it: LLM provider keys, cloud credentials and database secrets sitting inside Langflow flows.
Langflow is an open-source platform for building AI applications and agents by wiring components together visually. CVE-2026-55255 is an insecure direct object reference (IDOR): when a flow was resolved by its identifier, the lookup never checked who owned it, so any authenticated user could run another user's flow simply by supplying its UUID. On its own it is not remote code execution; it is an authorisation failure that hands over other people's data and secrets.
Sysdig's Threat Research Team observed it being exploited in the wild from 25 June. The operator first enumerated the existing flows, then reused those identifiers to read other users' flows, with an instruction as blunt as “leak api keys”. The wider objective was code execution, chaining a separate Langflow flaw, and delivery of a second-stage implant.
This incident is not really about Langflow. It is about a whole category of AI tooling we have rolled out quickly, often exposed to the internet and stuffed with credentials, without the governance we apply to everything else in production.
At a glance
If your organisation runs Langflow, or any similar platform for orchestrating AI, here is what matters today:
- Upgrade to version 1.9.2 or later without waiting for the next convenient maintenance window. The flaw is already being exploited.
- Take it off the public internet. No AI orchestration instance should be reachable directly: put it behind a VPN, single sign-on and network segmentation.
- If it was exposed, rotate the keys. Assume the credentials embedded in your flows (LLM, cloud, database) are compromised and change them now.
- Hunt for the pattern in your logs: enumeration of the flows interface followed by access to flows with different identifiers from the same source.
- Treat them as production. Langflow, n8n, Flowise or Dify need inventory, vulnerability management and monitoring like any other exposed service.
What CVE-2026-55255 is, conceptually
It is worth explaining the mechanics rather than a recipe. An IDOR appears when an application lets a user reach a resource by its identifier without checking whether that resource belongs to them. In Langflow, resolving a flow by UUID skipped that ownership check, so an authenticated user could invoke someone else's flow. The maintainers fixed it in the 1.9.x line; the guidance is to update to 1.9.2 or later.
Its score is not among the highest, and that is precisely the interesting part. It was exploited ahead of flaws with a far higher CVSS because it combined two things attackers look for: it was easy to abuse and it opened the door to something very valuable. This is the logic behind prioritising by real exploitability (KEV, EPSS and SSVC) rather than by theoretical severity alone.
As Sysdig puts it, a medium-severity vulnerability that is actually exploited does more damage than a perfect ten that nobody attacks. The KEV catalogue exists to reflect exactly that reality.
Why an AI flow is such a rewarding prize
Flows on these platforms tend to carry their secrets written straight into the component configuration: OpenAI or Anthropic keys, AWS credentials and database passwords. To an attacker they are liquid and immediate. They can be resold, or abused on the spot.
Abusing an LLM key has its own economics: the attacker burns your quota and leaves you the bill, or runs work on your account that they would rather not pay for. And a cloud or database credential rarely stays put; it is the launch point for moving towards connected services. This is the classic non-human identity (NHI) problem: machine credentials with broad permissions that almost nobody rotates and few teams watch.
A pattern we have already seen on these platforms
This is not the first time. Earlier this year Langflow carried CVE-2026-33017, an unauthenticated remote code execution flaw scoring 9.3, weaponised barely twenty hours after it went public. The same platform also served as the way in for the first ransomware run end to end by an AI agent that the industry documented recently.
Researchers now talk about a systemic pattern: this is the third class of remote code execution on AI platforms in the first quarter of 2026, and it recurs in tools such as n8n, Flowise, Dify and ComfyUI. The root cause is almost always the same: authentication disabled by default and tens of thousands of instances reachable from the internet.
Why traditional controls miss it
Many of these tools went up outside IT governance. A team wanted to prototype quickly, placed them on a public box to collaborate or run demos, and there they stayed. They have no patch owner, they are absent from the asset inventory, they fall outside the scope of vulnerability management, and their secrets never pass through a manager. It is attack surface the organisation does not know it has.
That is why it helps to look at it through two disciplines aimed squarely at that blind spot: attack surface management, to discover what is exposed, and a continuous threat exposure management (CTEM) approach, so that discovery is not a one-off exercise.
Operational detection
Without getting into how the attack is carried out, there are clear signals a defender can watch. Treat them as hunting hypotheses and adapt them to your telemetry:
- In the proxy and network logs, sequential access to the flows-listing interface followed by reads of flows with varying identifiers from the same session or IP address.
- Authenticated sessions walking through identifiers that do not belong to them: the tell-tale trace of an IDOR being exploited.
- Egress to LLM APIs (OpenAI, Anthropic) from hosts that should not be talking to them, or sudden spikes in usage and billing on your LLM or cloud accounts: a sign of stolen keys being abused.
- On the Langflow server itself, unexpected child processes or the download of second-stage artefacts, consistent with the chaining towards code execution.
If you have nobody to build and maintain those rules, that is exactly the job of a threat hunting service backed by threat intelligence.
Practical defence
The priorities, from greatest to smallest impact:
- Upgrade to 1.9.2 or later and confirm which version is deployed on every instance, including the ones you do not remember standing up.
- Remove public exposure: VPN, single sign-on and segmentation. These platforms should not be reachable from the internet.
- Stop embedding secrets in flows. Use a secrets manager and short-lived, minimally scoped credentials, not permanent keys with broad permissions.
- Rotate anything that may have been exposed (LLM, cloud and database keys) and review recent usage for anomalous access.
- Bring them under management. Fold these tools into your vulnerability management and into the monitoring of a managed SOC or an MSSP if you have no in-house team to watch them.
- Treat AI components as third parties. A model, a platform or an external connector belongs in your third-party risk management like any other supplier.
What it means for NIS2 and DORA
An exposed AI instance, with no owner and full of credentials, is exactly what NIS2 sets out to prevent: the directive calls for asset management, vulnerability handling and supply-chain security. You cannot protect, or report on, what you never inventoried.
For financial entities, DORA goes a step further: it requires ICT third-party risk to be registered and governed. An AI tool that concentrates cloud and database keys, and that is absent from that register, is an operational-resilience blind spot a supervisor will not overlook.
In short
The AI experimentation of the past two years created a new class of assets: internet-facing services, full of liquid secrets, deployed faster than governance could follow. CVE-2026-55255 is the reminder that attackers already know this. The answer is not to slow AI down but to govern it the way we govern everything else: inventory, authentication, managed secrets and monitoring. The boring measures, once again, are the ones that work.