TL;DR: CVE-2025-34291 in Langflow shows how wildcard credentialed CORS, cross-site refresh cookies, and authenticated code-execution paths can turn a browser visit into token theft and server-side compromise, according to Corgea. The issue is a governance failure around origin trust and secret exposure, not just a single code defect.
At a glance
What this is: This is an analysis of CVE-2025-34291 in Langflow, where permissive CORS and cross-site refresh-token handling allowed browser-based token theft that could progress to authenticated code execution.
Why it matters: It matters because AI workflow platforms often store API keys, cloud credentials, and database secrets, so a session hijack can become a broader identity and secrets incident for both NHI and human access programmes.
By the numbers:
- CISA added CVE-2025-34291 to the Known Exploited Vulnerabilities catalog on 21 May 2026.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
👉 Read Corgea's analysis of CVE-2025-34291 in Langflow
Context
Langflow is a browser-accessed AI workflow platform, which means its security model depends on tight boundaries between trusted origins, authenticated sessions, and server-side execution. When those boundaries blur, a simple web request can become an identity event that exposes tokens, then a secrets event that reaches cloud or database credentials.
The central governance problem is not just cross-site request handling. It is that AI workflow platforms frequently combine human browser sessions, long-lived refresh mechanisms, and highly privileged workspace secrets, so one weakness in origin validation can cascade into NHI compromise, account takeover, and code execution. That pattern is now familiar across AI tooling, and it is not atypical.
Key questions
Q: What breaks when refresh tokens can be read from cross-site browser requests?
A: The session boundary breaks first, because the attacker can exchange a victim browser interaction for usable credentials. Once refresh tokens are exposed, the attacker no longer needs to rely on the original page load. They can move into authenticated application actions, which is especially dangerous in systems that also expose workflow editing, validation, or secret-bearing integrations.
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 do security teams get wrong about CORS and CSRF in authenticated apps?
A: Teams often treat them as separate browser issues, but in practice they are linked. If an application allows credentialed cross-origin reads, the attacker may not just force a request, but also read the response and steal tokens. That is why origin policy, cookie scope, and CSRF protection must be designed together.
Q: Who is accountable when a platform's session design exposes server-side secrets?
A: Accountability usually sits with application owners, identity teams, and platform operators together, because the failure spans authentication, browser trust, and secret handling. Frameworks such as NIST CSF, OWASP NHI guidance, and internal secrets governance should all map to the same issue: a session control that can unlock privileged data or execution.
Technical breakdown
How wildcard CORS turns a browser session into token theft
Cross-origin resource sharing tells browsers which sites may read responses from an application. When a server allows credentialed requests from any origin and also sends cookies cross-site, an attacker can host a malicious page that makes an authenticated request on behalf of the victim and reads the response. In this case, the refresh token cookie and permissive CORS combine to create a token disclosure path, not just a request forgery path. That changes the browser from a client into a credential relay.
Practical implication: enforce explicit origin allowlists and disable credentialed cross-origin access wherever the application does not need it.
Why token refresh becomes a privilege bridge in AI workflow apps
A refresh endpoint is meant to exchange a valid session artifact for fresh access credentials. If an attacker can read the refresh response, they no longer need the victim's browser session after the first request, because they now hold usable tokens. In workflow platforms, those tokens often unlock management APIs, flow editing, validation, and integration settings. The security boundary is therefore not the login page alone, but the entire token lifecycle that follows authentication.
Practical implication: treat refresh endpoints as high-value identity surfaces and add CSRF-resistant design, not only login hardening.
How authenticated code validation expands the blast radius
Workflow builders often validate custom components by executing or partially executing code in the application context. That can be safe only when the caller is strongly authenticated and constrained. Once stolen tokens grant access, the attacker can reach code paths that were meant for trusted users, and those paths may execute with server permissions. In an AI platform, that can expose stored secrets, read environment variables, or reach downstream systems connected to the workspace.
Practical implication: separate code-execution features from ordinary workflow management and restrict them with stronger approvals, isolation, or removal where unnecessary.
Threat narrative
Attacker objective: The attacker wants to hijack a legitimate Langflow session, obtain usable tokens, and pivot into authenticated access that can expose or execute against high-value workspace secrets.
- Entry occurs when a victim with an active Langflow session visits an attacker-controlled page that can issue cross-site requests to the application.
- Credential access follows when the browser sends the refresh_token_lf cookie and the attacker reads fresh access and refresh tokens from the refresh response.
- Escalation happens when the stolen tokens are used against authenticated Langflow APIs, including code-validation and workflow-management paths.
- Impact is server-side compromise and potential exposure of workspace secrets such as API keys, database credentials, cloud tokens, and model provider credentials.
Breaches seen in the wild
- Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
- GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Origin trust failure is now an identity control failure. CVE-2025-34291 is not just a CORS bug. It shows that browser origin policy, cookie scope, and token refresh design now sit inside the identity control plane for AI workflow platforms. When an application accepts credentialed cross-origin reads, the session boundary collapses before PAM or access review can even begin. Practitioners should treat origin validation as a governance control, not a web hardening detail.
AI workflow platforms create a new form of secret concentration. Langflow-style systems often sit at the intersection of human users, service credentials, and NHI material such as API keys and cloud tokens. That makes them a high-density credential environment where one stolen session can reach multiple secret classes. The governance question is no longer whether the platform is authenticated, but whether its execution paths and stored variables are compartmentalised enough to survive token theft.
Browser-mediated token theft is a standing-privilege problem in disguise. The attacker does not need to own infrastructure if the victim's browser and cookies can be used as the transport layer. This is the same structural problem seen in other token-hijack cases: access persists long enough to be abused, and the defender sees ordinary user traffic until it is too late. Zero standing privilege thinking should extend to web sessions that can unlock code execution and secret access.
Langflow exposes a named governance gap: refresh-token trust without origin containment. The vulnerable chain worked because the application trusted a refresh cookie in contexts where the browser should not have been able to present or reveal it. That is a specific failure mode, not a generic misconfiguration. For identity teams, the practical conclusion is that session architecture must be reviewed alongside secrets handling whenever a platform exposes both browser access and privileged workflow automation.
AI agent platforms are becoming part of the NHI attack surface. Even where the article focuses on human browser sessions, the downstream compromise lands on machine credentials, provider tokens, and workflow secrets that power AI systems. That intersection means NHI governance, secrets rotation, and application trust boundaries now have to be evaluated together. Practitioners should stop separating AI tooling security from identity governance, because the blast radius is already shared.
From our research:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- From our research: 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
- The fastest-moving response is rotation plus revocation, because exposed credentials often remain live long after discovery and can be abused from legitimate-looking sessions.
What this signals
Refresh-token trust without origin containment is now a repeatable attack pattern. Teams running AI workflow platforms should assume browser-mediated token theft will keep surfacing wherever cross-site credentialed requests and privileged refresh endpoints coexist. Align session design to the browser threat model, then validate that the platform cannot both send and read secrets cross-origin.
Identity and secrets ownership will need to converge around AI platforms that store workflow credentials. When human sessions can unlock machine tokens, the programme boundary between IAM and NHI governance becomes operationally meaningless. Map those systems to NIST AI Risk Management Framework for governance and to OWASP Agentic AI Top 10 where workflow automation and delegated actions are in scope.
Credential-harvest latency should drive detection design. Once secrets leak, attacker action can begin within minutes rather than days, so alerting must focus on origin anomalies, refresh bursts, and downstream privilege use rather than waiting for obvious abuse. That is especially true where workspace secrets, provider tokens, and server-side execution live in the same application context.
For practitioners
- Harden credentialed cross-origin access Replace wildcard origins with an explicit allowlist and review every endpoint that accepts credentials in a browser context, especially refresh and session exchange routes.
- Rework refresh-token handling Set refresh cookies to a same-site value that matches the deployment model, require anti-CSRF protections on refresh flows, and verify that the browser cannot both send and expose tokens cross-site.
- Separate code execution from routine workflow access Isolate or restrict custom-component validation and any Python execution path so that stolen session tokens do not immediately grant server-side execution capability.
- Rotate exposed workspace secrets immediately after suspicion Assume provider keys, database credentials, cloud tokens, and any environment secrets reachable from the Langflow process may already be exposed, then rotate and validate downstream access logs.
- Add reachability-based detection and response Alert on cross-origin refresh activity, token refresh bursts, and unusual validation calls that follow browser-origin requests, because IP reputation alone will not identify this exploit reliably.
Key takeaways
- CVE-2025-34291 shows that credentialed cross-origin reads can turn a logged-in browser into a token-stealing path.
- The blast radius is larger than session hijack because AI workflow platforms often store NHI material and can execute code server-side.
- The control failure is specific: origin validation, cookie scope, and CSRF protections must be designed together, then paired with secret rotation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | The article centers on exposed refresh and workspace secrets in an AI workflow platform. |
| MITRE ATT&CK | TA0006 , Credential Access; TA0004 , Privilege Escalation; TA0002 , Execution | The exploit steals tokens, then uses them to reach code execution paths. |
| NIST CSF 2.0 | PR.AC-4 | Session trust and access boundaries failed across browser and application layers. |
| NIST SP 800-53 Rev 5 | IA-5 | The issue revolves around authentication material and its lifecycle. |
| NIST Zero Trust (SP 800-207) | The incident shows why trust should be continuously verified across origins and sessions. |
Re-evaluate browser and application trust assumptions under a zero-trust model before permitting credentialed cross-origin access.
Key terms
- Credentialed Cross-Origin Request: A cross-origin request that carries cookies or other authentication context. These requests are higher risk because origin approval can expose authenticated sessions to browser-based interaction from a broader trust set than intended.
- Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
- Server-side execution: Server-side execution occurs when code runs in the application host environment rather than in a user browser. If an attacker can trigger it through crafted input, the server may reveal secrets, access internal resources, or become a foothold for broader compromise.
- Workspace Secret: A credential stored inside an application environment for use by workflows, integrations, or automation. Examples include API keys, database passwords, cloud tokens, and service account credentials. These secrets often become the real impact layer after an identity compromise.
What's in the full analysis
Corgea's full research covers the operational detail this post intentionally leaves for the source:
- Configuration examples for hardening LANGFLOW_CORS_ORIGINS, LANGFLOW_CORS_ALLOW_CREDENTIALS, and refresh cookie behaviour
- Log review patterns for cross-origin /api/v1/refresh activity, token bursts, and suspicious validation calls
- Upgrade and container rollout steps for moving from vulnerable Langflow versions to the fixed release line
- Remediation guidance for rotating workspace secrets, provider tokens, and cloud credentials after suspected exposure
👉 The full Corgea post covers the exploit chain, affected settings, and remediation steps in detail.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in the context of real-world control failures. It helps security practitioners connect identity design to operational risk across AI platforms and the systems they expose.
Published by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org