What is CVE-2026-55255?

CVE-2026-55255 is a cross-tenant insecure direct object reference (IDOR) in Langflow, rated CVSS 9.9. An authenticated user on one tenant can reference and read stored objects belonging to other tenants, including embedded secrets such as LLM provider keys, cloud credentials, and database passwords. Help Net Security reported active exploitation on July 8, 2026, and CISA added the vulnerability to its Known Exploited Vulnerabilities catalog with a federal civilian mitigation deadline of July 10, 2026. The severity comes from what Langflow stores alongside the multi-tenant object graph, since flows persist long-lived provider keys so they can run unattended.

Would an AI gateway have prevented the Langflow exploit?

An AI gateway does not patch an application's missing tenant check, so it would not have closed the Langflow IDOR itself. What it changes is the blast radius and the evidence. A stateless enforcement layer that holds no long-lived provider keys removes the high-value secret an IDOR would otherwise reach. Binding every model call to a verified identity means a harvested credential maps to a real actor rather than a shared account. Per-decision audit records show which identity made which call during the exploitation window. The gateway is a compensating control and an audit source, not a substitute for patching the vulnerable component.

How should we store LLM provider keys to reduce this risk?

Keep long-lived provider keys out of the layer that faces multi-tenant user traffic. Where a component must call a model, prefer short-lived, scoped credentials issued at request time and bound to a single identity and route, so a harvested secret expires quickly and reaches little. Store any persistent secrets in a dedicated secret manager with its own access controls rather than in the same datastore as tenant-scoped application objects. Add an external enforcement point in front of AI traffic so isolation and authorization are evaluated independently of the application that might skip a check.

What does the CISA KEV listing require?

Listing in the CISA Known Exploited Vulnerabilities catalog obligates federal civilian executive branch agencies to remediate by the assigned deadline, which for CVE-2026-55255 was July 10, 2026. The deadline binds those agencies directly, and for private organizations the listing still carries weight as a signal that the vulnerability is being exploited now, which raises its practical priority above its base score alone. Teams running Langflow should apply the vendor fix, rotate any provider keys and credentials that were stored in affected flows, and review access logs for cross-tenant object r

Langflow CVE-2026-55255: Multi-Tenant Secret Isolation and AI Provider Keys

On July 8, 2026, Help Net Security reported that CVE-2026-55255 was being exploited in the wild. The bug is a CVSS 9.9 cross-tenant insecure direct object reference (IDOR) in Langflow, the visual builder for LLM applications. An authenticated user on one tenant can read objects that belong to a different tenant, including the secrets those tenants embedded in their flows: LLM provider keys, cloud credentials, and database passwords. CISA added it to the Known Exploited Vulnerabilities catalog and set a federal civilian mitigation deadline of July 10, 2026.

I want to walk through the exploitation path, the reason a single isolation flaw turns into wholesale provider-key theft, and the one architectural property that limits the blast radius: where the keys live in the first place.

CVE-2026-55255 mechanism

The vulnerability sits in Langflow's object authorization. A request references a stored object by identifier, and the server returns it without confirming that the identifier belongs to the caller's tenant. That is the textbook IDOR shape, and on its own it would be a data-exposure bug. What raises it to CVSS 9.9 is what Langflow stores next to the multi-tenant object graph: the provider keys and credentials each flow needs at runtime.

Langflow flows call OpenAI, Anthropic, Bedrock, and other model endpoints. To do that, the flow holds a long-lived API key. Those keys are persisted so the flow can run unattended. The IDOR gives an attacker on a free or low-cost tenant a way to enumerate other tenants' stored objects and harvest the secrets attached to them. CISA's KEV entry records the active-exploitation status that moved this from a patch-when-convenient advisory to a same-week deadline.

Why one isolation flaw becomes provider-key theft

An IDOR is a single missing check. The damage it does depends entirely on what sits behind the check. When an AI orchestration tool stores long-lived provider keys in the same datastore as tenant-scoped objects, any isolation flaw promotes from data exposure to credential theft in one step.

Harvested provider keys are worth more than most data. A stolen OpenAI or Anthropic key runs up spend on the victim's account, and it also grants the attacker a working identity to send model traffic that looks legitimate. A stolen cloud credential reaches storage buckets, secret managers, and compute. The Langflow case follows a pattern I covered in the LiteLLM June CVE analysis: the highest-value target in an AI stack is often the layer that stores keys, not the model.

Where the keys live is the design decision

Most AI tooling defaults to storing long-lived provider keys because it is the shortest path to a working demo. The key gets pasted into a flow, saved to the database, and reused on every run. That default is what turns an isolation bug into a secret-harvest event.

Two design choices change the exposure:

Hold no long-lived provider keys at the layer users interact with. If the component that faces multi-tenant traffic never persists a provider key, an IDOR against it returns objects with nothing valuable attached.
Bind every model call to a verified identity, and issue short-lived scoped credentials at request time. A credential that lives for the duration of one request, scoped to one identity and one route, is worth little if harvested later.

A stateless proxy fits this shape. It evaluates each request against the identity the application supplies, applies per-route and per-role policy, and forwards the call. I described the trade-offs of that pattern in stateless vs stateful AI proxies. The property that matters here is custody: a stateless enforcement layer holds no long-lived provider secret for an attacker to reach.

Multi-tenant isolation is an evaluation question

Tenant isolation fails quietly. The code path that skips a tenant check looks the same as the code path that performs one, until someone enumerates identifiers. This is why isolation cannot rest on application logic alone in a regulated deployment.

An external enforcement point that sits in front of AI traffic gives isolation a second, independent evaluation. Every request carries the identity and tenant context the application asserts, and policy at the gateway decides whether that identity is permitted to make this call with this data. I walked through the category distinctions in AI firewall vs AI gateway vs AI proxy and the multi-tenant specifics in AI gateway multi-tenant isolation. The point is not that a gateway patches Langflow's IDOR. The point is that identity-bound evaluation and per-decision records give you a control and an audit trail that do not depend on the vulnerable application getting its own tenant check right.

The exploitation window argument

CISA gave federal agencies two days. Everyone else operates on their own patch cadence, and active exploitation means the window between disclosure and compromise is already open. Patching is the fix. It is also slower than the attack.

Between disclosure and patch, the compensating control is architectural. A deployment where the AI-facing layer holds no long-lived provider keys, binds calls to identity, and records every decision has less to lose during the window and a cleaner forensic record afterward. Compensating controls do not replace the patch. They hold the line while the patch ships.

DeepInspect

This is the architecture DeepInspect provides. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users or agents and any HTTP LLM endpoint. It evaluates every request against the identity the application supplies, applies per-route and per-role policy, and produces a signed, per-decision audit record. It holds no long-lived provider keys as a store for an attacker to enumerate, and it binds each call to a verified identity rather than a shared service credential.

For a bug like CVE-2026-55255, that changes the shape of the exposure. An enforcement layer that keeps no persistent provider secret gives a secret-harvest flaw far less to reach, and the per-decision record shows which identity made which model call during the exploitation window. The isolation guarantee stops depending on the vulnerable application evaluating its own tenant boundary correctly.

If you are running LLM orchestration tooling in a multi-tenant or regulated environment and your provider keys sit in the same store as tenant data, book a demo today.