# Langflow CORS Origin Bypass and SameSite=None Refresh Token Theft

- **Severity:** Medium
- **Signature ID:** `b7f3c2d1-4e8a-4c19-9f6b-2d5a8e0c7413`
- **CVEs:** CVE-2025-34291
- **OWASP:** LLM02 (Sensitive Information Disclosure)

## Summary

Langflow, an AI workflow builder, had a bug where its authentication cookies could be marked to work across different websites (SameSite=None) while also allowing overly permissive cross-origin requests. Combined, this lets a malicious website silently steal a logged-in user's refresh token and reuse it to hijack their Langflow session. This rule looks for text patterns showing the pieces of that attack in network traffic.

## How the attack works

An attacker hosts a page on a different origin that makes a credentialed request (using an absolute URL, since Langflow's own frontend never needs to) to a Langflow authentication endpoint. If Langflow's CORS settings wrongly allow any origin (*) alongside credentials, the browser will send the victim's session cookie anyway. The stolen refresh token can then show up embedded directly in a request body (rather than as a normal cookie), indicating it's being relayed or exfiltrated. The rule flags four specific combinations of these elements found in a single outbound web request; it does not track the full multi-step sequence, only these fragments.

## Why it matters

If successfully exploited, an attacker can hijack a user's authenticated session in Langflow, potentially chaining it into further compromise (per the CVE, up to remote code execution) without needing the victim's password.

## What you can do

- Ensure Langflow's CORS configuration does not combine allow_origins="*" with allow_credentials=True; restrict allowed origins to trusted hosts.
- Set authentication cookies (refresh_token_lf, access_token_lf, apikey_tkn_lflw) to SameSite=Strict or Lax, not None, unless cross-site use is truly required.
- Review any alerts from this rule manually — legitimate admin tooling and CI/CD deployment of Langflow's default CORS config can trigger the same pattern, so expect false positives.
- Audit browser-automation or integration tools that handle Langflow refresh tokens to confirm they don't pass tokens in JSON bodies unnecessarily.

## Known benign look-alikes

- Platform or IaC agents legitimately pushing Langflow FastAPI CORSMiddleware configuration (allow_origins=["*"] with allow_credentials=True is Langflow's own shipped default) via a deployment or repository API — matches branch D.
- Security researchers or vulnerability-scanning agents transmitting a proof of concept for this CVE; largely suppressed by the paired CVE-id + advisory-prose filter, but a bare PoC with no advisory wording will still report.
- Browser-automation or end-to-end integration agents that authenticate to a Langflow instance and carry the resulting refresh JWT in a JSON body rather than a Cookie header — matches branch C.
- A legitimate companion single-page app, hosted on a different origin by design, whose reviewed source calls an absolute Langflow /api/v1/refresh URL with credentials:'include' — matches branch A. This is the intended signal even when sanctioned, because it is indistinguishable from the attack at the HTTP layer.
- Session-restore or backup payloads from a Langflow SDK that serialise the refresh_token_lf cookie name together with its SameSite attribute — branch B.

## References

- https://attack.mitre.org/techniques/T1539/
- https://attack.mitre.org/techniques/T1550/004/

---
Source: https://www.netzilo.com/threats/langflow-cors-samesite-token-theft