Langflow account takeover exposes the NHI blast radius in AI workflows

At a glance

What this is: This is an analysis of a critical Langflow vulnerability chain that combines CORS, CSRF, and code execution flaws into account takeover and remote code execution.

Why it matters: It matters because AI workflow platforms often store high-value NHI secrets, so one browser-driven compromise can spread into cloud and SaaS integrations.

By the numbers:

• The flaw is tracked as CVE-2025-34291 and carries a CVSS v4.0 score of 9.4.

👉 Read Obsidian Security's analysis of the Langflow CVE-2025-34291 vulnerability chain

Context

Langflow sits in the middle of a growing identity problem for AI workflows. These platforms do not just run logic, they concentrate service accounts, API keys, tokens, and other secrets that connect cloud and SaaS systems. When a workflow platform is reachable through a browser and can touch downstream credentials, its security posture becomes an NHI governance issue, not just an application issue.

The Langflow case shows how quickly small control failures can compose into a full compromise. Permissive cross-origin access, weak cookie handling, and an endpoint designed to execute code created an attack path from a simple webpage visit to session hijack and remote code execution. That pattern is not unique to one vendor or one project; it is typical of AI platforms that grew faster than their access boundaries.

The key lesson is that AI agent and workflow platforms should be treated as identity brokers with code execution risk, because that is how attackers will treat them.

Key questions

Q: How should security teams protect NHI secrets stored in AI workflow platforms?

A: Start by assuming the platform is a high-value identity concentrator. Limit which connectors can store long-lived secrets, scope every token to the smallest viable system, and rotate credentials that the platform can expose broadly. Pair that with strict access review, because compromise of one workflow workspace should not become a path to many downstream systems.

Q: Why do AI workflow platforms create a larger identity risk than a normal app server?

A: They often sit between users and many downstream services, so they accumulate tokens, API keys, and service accounts in one place. That concentration increases blast radius because an attacker who reaches the platform may inherit access to cloud, SaaS, and internal systems that trust those secrets.

Q: What is the difference between CSRF protection and CORS hardening in this context?

A: CORS controls which origins a browser may talk to, while CSRF protection proves that an authenticated request was intentionally made by the user. Both matter, but they solve different problems. A platform can have restrictive CORS and still be vulnerable if cookie-based refresh endpoints accept cross-site requests without CSRF checks.

Q: When should organisations sandbox code execution in agentic platforms?

A: Sandboxing should be the default whenever user-defined code, custom components, or validation routines can execute logic inside the platform. If the platform can touch production credentials or downstream systems, unsandboxed execution turns a configuration feature into a breach path.

Technical breakdown

How CORS and CSRF turn a browser into an attack relay

Cross-Origin Resource Sharing, or CORS, determines which external origins a browser may talk to. When a platform allows credentialed requests from arbitrary origins, the browser can become a relay for authenticated actions initiated by an attacker. CSRF, or cross-site request forgery, blocks that pattern by requiring a request-specific proof that the user actually intended the action. If a refresh endpoint depends on browser cookies but lacks CSRF checks, the browser can silently attach those cookies during a cross-site request. That combination is dangerous because the attacker never needs to know the credential value. The browser supplies it for them, and the application treats the request as legitimate.

Practical implication: Restrict credentialed origins and require explicit CSRF defenses anywhere cookies can refresh or mint NHI sessions.

Why code-validation endpoints become an execution boundary

A code-validation endpoint is not a harmless parser when it executes user-submitted snippets to inspect them. In Python, functions can run code through default arguments and decorators during evaluation, so validation can become execution if it is not sandboxed. In AI workflow platforms, this matters because custom components often need dynamic inspection, but dynamic inspection expands the trust boundary. If the endpoint is reachable without strong auth or isolation, an attacker can move from request forgery to direct command execution. The issue is not only the code path itself. It is the decision to let untrusted input cross from validation into runtime semantics.

Practical implication: Put code evaluation behind strong authentication, isolate it from the main control plane, and sandbox it by default.

Identity blast radius in AI workflow platforms

AI workflow platforms often store many downstream credentials in one workspace, which turns a single compromised session into a multi-system incident. That is the identity blast radius problem: one control failure exposes the access tokens and API keys that govern many other systems. Once those secrets are reachable, attackers do not need to stay inside the platform. They can pivot into SaaS, cloud, and internal services that trust the compromised NHI. This is why platform security cannot stop at the app boundary. The real control question is how much standing access the platform can touch and how much damage that access can cause.

Practical implication: Map every stored secret and downstream connector, then reduce the number of credentials any one workspace can expose.

Threat narrative

Attacker objective: The attacker aims to seize the platform session, execute code, and harvest downstream NHI secrets for broader compromise.

1. Entry via a malicious webpage that triggers a cross-origin request from a logged-in user’s browser.
2. Escalation through token refresh abuse, where permissive CORS and missing CSRF protections allow session hijack.
3. Impact through authenticated access to a code-validation endpoint that can be used for remote code execution and secret exposure.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser-mediated compromise is now an NHI attack path, not just an application bug. When a platform uses cookies, tokens, and permissive cross-origin behaviour to drive authenticated workflows, the browser becomes part of the trust boundary. That matters for NHI governance because service credentials often sit behind the same session mechanics as human users. Practitioners should treat browser-driven token minting as a privileged control surface, not a convenience feature.

Identity blast radius is the right concept for AI workflow platforms. These systems aggregate downstream access in one place, so compromise of the platform often means compromise of many connected systems. The term captures a broader reality than simple account takeover because the issue is not only who logs in, but what secrets the platform can reach next. Teams should measure the blast radius of each workspace, connector, and stored token before expanding adoption.

Code execution inside an AI workflow platform changes the governance model. Validation endpoints, custom component loaders, and low-code execution paths blur the line between configuration and runtime. Once that boundary is blurred, standard application hardening is not enough; NHI controls need to include sandboxing, secret scoping, and connector isolation. Practitioners should assume that any platform able to execute user-defined logic must be governed like a high-risk execution environment.

Small misconfigurations can create a severe control failure when they combine. Permissive CORS, weak cookie settings, and missing CSRF protection are each familiar issues on their own, but together they create a complete exploit chain. That pattern is common in fast-moving AI infrastructure where usability decisions outrun threat modelling. Security teams should review control combinations, not just individual findings, before declaring a workflow platform safe.

AI agent governance must include downstream secret inventory and session hygiene. The security question is not only whether the agent or workflow platform is authenticated, but whether it can expose credentials that unlock adjacent systems. That shifts governance from endpoint hardening toward secret minimisation, connector review, and blast-radius reduction. Teams should use this class of issue to pressure-test how much standing access their AI workflows actually hold.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• For deeper NHI context, see The 52 NHI breaches Report for patterns that show how a single exposed credential can cascade across connected systems.

What this signals

Identity blast radius should become a core planning metric for AI workflow platforms. The practical question is no longer whether a platform can authenticate users, but how much downstream access one compromised session can expose. With 80% of organisations already reporting AI agents acting beyond intended scope, according to AI Agents: The New Attack Surface report, the governance gap is already visible in production environments.

Teams should assume that browser-facing workflow tools will be reviewed through the same lens as privileged infrastructure. That means tighter connector scoping, stronger token hygiene, and explicit approval for any workflow that can mint or refresh credentials. For zero-trust programs, the relevant benchmark is not whether access exists, but whether access can be continuously constrained and revoked.

The next control discussion will centre on secret minimisation and execution isolation, not just login hardening. If a platform can validate code and store downstream tokens, then a single design flaw can combine identity compromise with runtime compromise. Practitioners should prepare for more security review of agent builders, visual workflow tools, and other NHI-heavy control planes.

For practitioners

• Harden cookie-backed refresh flows immediately Require explicit CSRF protection for any endpoint that mints or refreshes session tokens, and remove wildcard credentialed origins from browser-facing deployments.
• Inventory every secret the platform can reach Map API keys, service tokens, and database passwords stored in workspaces, then classify which downstream systems each one can access.
• Sandbox all code-validation and custom component paths Treat code evaluation as execution, isolate it from the main app, and deny access to production secrets unless a workflow truly needs them.
• Reduce standing access in connected systems Replace broad connector credentials with task-scoped access where possible, and rotate any long-lived secrets exposed to the workflow platform.
• Test the browser attack path, not just the API path Include cross-origin request handling and cookie attachment in security review, because a compromised browser session may be the easiest entry point.

Key takeaways

• A browser-driven exploit chain can turn an AI workflow platform into an NHI compromise multiplier.
• The material risk is not just account takeover, but exposure of the secrets that connect cloud and SaaS systems.
• Security teams should review code execution, cookie handling, and connector scoping together, because the attack only needs one combined failure.

Key terms

• Identity Blast Radius: The identity blast radius is the amount of downstream access that can be reached if one NHI, workspace, or control plane is compromised. In AI workflow platforms, it is often larger than teams expect because a single session may expose many connected services and their secrets.
• Cross-Site Request Forgery: Cross-site request forgery is a technique that tricks a logged-in browser into sending authenticated requests the user did not intend. It matters in NHI-heavy systems because cookie-backed token refresh or session renewal can be abused without ever learning the underlying secret.
• Code-Execution Boundary: A code-execution boundary is the point where a system stops inspecting input and starts running it. In workflow platforms, that boundary is especially sensitive because validation, custom components, and automation logic can all turn untrusted content into privileged runtime actions.

Deepen your knowledge

AI workflow platform governance and NHI blast-radius reduction are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for platforms that store tokens, keys, or service accounts, it is worth exploring.

This post draws on content published by Obsidian Security: CVE-2025-34291 and the Langflow account takeover vulnerability chain. Read the original.