Join our Newsletter — 33% off our NHI Course

Notifications
Clear all

Langflow CVE-2025-34291: why CORS and refresh tokens turned risky


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 18936
Topic starter  

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.

NHIMG editorial — based on content published by Corgea covering CVE-2025-34291 in Langflow: browser-based token theft and server-side code execution risk

By the numbers:

Questions worth separating out

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.

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.

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.

Practitioner guidance

  • 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.

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

👉 Read Corgea's analysis of CVE-2025-34291 in Langflow →

Langflow CVE-2025-34291: why CORS and refresh tokens turned risky?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 18527
 

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.

A few things that frame the scale:

A question worth separating out:

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.

👉 Read our full editorial: Langflow CVE-2025-34291 shows how browser trust becomes RCE



   
ReplyQuote
Share: