What Happened
Attackers are actively exploiting CVE-2026-55255, an Insecure Direct Object Reference (IDOR) vulnerability in Langflow's /api/v1/responses endpoint. This flaw allows anyone to execute workflows belonging to other users without authentication. The Sysdig Threat Research Team observed attackers injecting a "leak API keys" prompt into hijacked flows to extract embedded credentials from victim workflows.
This is not a theoretical issue. It's happening now in production environments running vulnerable Langflow instances.
Timeline
The exploitation pattern shows attackers moving quickly:
- Vulnerability disclosed in Langflow.
- CISA adds CVE-2026-55255 to its Known Exploited Vulnerabilities catalog.
- Active exploitation observed by Sysdig's threat research team.
- Patch deadline for US federal agencies: July 10, 2026.
If you're running Langflow in a multi-tenant environment, you can't afford to wait for the federal deadline.
Which Controls Failed or Were Missing
Three authorization failures created this exposure:
Missing object-level authorization checks. The /api/v1/responses endpoint executed workflows based solely on a workflow ID in the request. No validation checked whether the requesting user owned that workflow. If you knew or guessed a valid workflow ID, you could run it.
Lack of tenant isolation. In multi-tenant deployments, workflows from different organizations shared the same namespace. An attacker in Tenant A could reference and execute workflows in Tenant B. The system treated workflow IDs as universally accessible rather than scoping them to the authenticated user's context.
Insufficient input validation. The endpoint accepted workflow execution requests without verifying the source. This allowed attackers to inject malicious prompts into flows they didn't own, turning legitimate workflows into credential harvesters.
What the Relevant Standard Requires
OWASP API Security Top 10 (2023) - API1:2023 Broken Object Level Authorization. This is the canonical example. The standard explicitly requires: "Implement a proper authorization mechanism that relies on user policies and hierarchy. Use the authorization mechanism to check if the logged-in user has access to perform the requested action on the record in every function that uses an input from the client to access a record in the database."
Langflow's endpoint violated this by accepting workflow IDs without checking ownership.
PCI DSS v4.0.1 Requirement 6.4.2. For any application handling payment data: "Common coding vulnerabilities are addressed in software-development processes as follows: Developers are trained at least once every 12 months in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities." IDOR vulnerabilities qualify as common coding vulnerabilities that training should cover.
OWASP ASVS v4.0.3 Section 4.1.2. "Verify that the application enforces access controls at a trusted service layer, especially if client-side access control is present and could be bypassed." The API layer is that trusted service layer. Trusting client-provided workflow IDs without server-side validation fails this requirement.
ISO/IEC 27001:2022 Control 8.3 (Information access restriction). Organizations must "restrict access to information and other associated assets to authorized users." Allowing unauthenticated workflow execution directly violates this control.
SOC 2 Type II CC6.1 (Logical and Physical Access Controls). Service organizations must "implement logical access security measures to protect against threats from sources outside its system boundaries." An endpoint that accepts arbitrary workflow IDs from any source fails this criterion.
Lessons and Action Items for Your Team
Audit every API endpoint that accepts object identifiers. Don't wait for a CVE. Review your codebase and find every endpoint that takes an ID, UUID, or reference to a resource. For each one, verify you're checking: Does this user own this object? Does this user have permission to perform this action on this object?
Start with this SQL pattern:
SELECT * FROM workflows WHERE id = :user_provided_id
That's wrong. You need:
SELECT * FROM workflows
WHERE id = :user_provided_id
AND owner_id = :authenticated_user_id
Implement tenant isolation at the database level. If you're running multi-tenant SaaS, partition data by tenant ID. Use row-level security policies in PostgreSQL or equivalent mechanisms in your database. Make it structurally impossible for queries from Tenant A to return data from Tenant B, even if your application code fails.
Never trust workflow IDs or execution requests from clients. Treat every user-provided identifier as hostile. Your authorization logic should answer: "Can this specific authenticated user perform this specific action on this specific resource?" If any part of that check is missing, you have an IDOR vulnerability waiting to be exploited.
Scan for embedded credentials in user-generated content. The Sysdig observation about injected prompts harvesting API keys reveals a secondary problem: workflows contained embedded credentials. Use secret scanning tools like GitGuardian, TruffleHog, or GitHub's built-in secret scanning on any user-generated content your platform stores. This includes workflow definitions, configuration files, and template repositories.
Patch Langflow immediately if you're running it. CISA doesn't add vulnerabilities to the KEV catalog for theoretical risks. Active exploitation means attackers have working exploits and they're using them. Update to the patched version, then audit your logs for suspicious workflow executions from the past 30 days.
Build IDOR testing into your security regression suite. Create test cases that attempt to access objects belonging to other users. These tests should fail if your authorization works correctly. Run them on every pull request. IDOR vulnerabilities are preventable through systematic testing, but only if you actually test for them.
The Langflow incident proves that authorization failures in multi-tenant environments don't just leak data between users. They let attackers weaponize your platform's features against your users. Fix your authorization checks before someone demonstrates what that means for your customers.
