Langflow CORS Origin Bypass and SameSite=None Refresh Token Theft
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.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- b7f3c2d1-4e8a-4c19-9f6b-2d5a8e0c7413
- Severity
- Medium
- CVEs
- CVE-2025-34291
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.