What CISA actually listed

CISA added CVE-2025-34291 to its Known Exploited Vulnerabilities catalog on May 21, 2026, with a remediation deadline of June 4, 2026. NVD describes it as a chained vulnerability in Langflow up to and including 1.6.9 that ends in account takeover and remote code execution. When I traced the chain, none of the individual links are exotic, which is what makes it worth writing up: it is four ordinary web mistakes stacked on a platform that should never have been treated as low-risk.

This is the earlier of two KEV-listed Langflow flaws. If you run Langflow, also read the later, separately exploited authorization bypass in CVE-2026-55255 (Langflow IDOR). Both point at the same underlying problem: LLM orchestration platforms are internet-exposed, credential-rich, and under-inventoried.

Why a CORS bug matters more here than on most apps

On a typical web app, stealing a session gets you that app. On Langflow, I have to assume the session gets an attacker everything the flows can reach, because that is where teams store API keys, model credentials, SaaS tokens, and database connectors. GitHub's advisory is blunt about the outcome: an attacker-controlled origin obtains fresh access and refresh token pairs for a victim session, then calls authenticated endpoints, including built-in code execution. So I score this less on the CVSS number and more on "what is one flow away from the box."

The chain, in order

The root cause is an origin validation error: Langflow accepted credentialed cross-origin requests from any origin, and the refresh-token cookie was set in a way that let a browser carry the attack. NVD summarises it as:

allow_origins = '*'          # any origin accepted
allow_credentials = True     # ...with cookies/credentials
SameSite = None              # refresh-token cookie sent cross-site
  ↓
cross-origin credentialed request to the refresh endpoint
  ↓
access + refresh token theft
  ↓
authenticated endpoint access → remote code execution

allow_origins='*' together with allow_credentials=True is the mistake I see most often in code review, and it is usually harmless because there is nothing sensitive behind it. Here the browser forwards the victim's cookies to the malicious origin, and the SameSite=None refresh cookie lets the attacker's page mint new tokens. CVSS v4.0 9.4 Critical from the CNA: network vector, low complexity, no privileges, passive user interaction. The blast radius, for exposed instances: session takeover, access to stored flows and integrations, code execution on the host, and a pivot into whatever cloud, SaaS, database, or internal service those flows touch.

Check your version first

NVD lists Langflow ≤ 1.6.9. Before anything else, find out what you are running, and where:

# Python package deployment
pip show langflow

# Container deployment
docker ps --format '{{.Image}}' | grep -i langflow
docker image ls | grep -i langflow

If you're exposed: patch, then rotate every secret

Upgrade above 1.6.9. CISA's required action is vendor mitigations, BOD 22-01 guidance for cloud services, or discontinuing use if no fix is available.

# Upgrade the Python package
pip install --upgrade langflow
# For Docker, pull/rebuild the updated image per your deployment method

Patching stops new token theft; it does nothing about tokens already taken. If the instance was reachable while vulnerable, I treat the stored secrets as burned, they are the actual prize here, not the Langflow login. Rotate API keys, model credentials, and connector secrets, then review reverse-proxy auth, recent workflow executions, outbound connections, and the Langflow logs around token-refresh activity.

Keeping it off the internet

My baseline for Langflow is that it never faces the internet directly:

  • Front it with a VPN, Tailscale, or a Zero Trust proxy, plus SSO.
  • Set explicit allowed origins. Never wildcard credentialed CORS.
  • Short-lived sessions; rotate secrets after any patch.
  • Container isolation and egress filtering, so a compromised instance cannot freely call out.

For Docker Compose, bind to localhost and terminate TLS and auth in front:

ports:
  - "127.0.0.1:7860:7860"   # not 0.0.0.0

What I'd hunt for

Unexpected POSTs to refresh endpoints, Origin headers from domains you do not recognise, new access tokens issued right after odd cross-origin traffic, workflow or code execution within seconds of a token refresh, new or modified flows, outbound traffic from Langflow containers, and access from unfamiliar IPs or user agents. On Linux hosts:

docker logs <langflow_container> --since 72h | grep -Ei "refresh|origin|token"
journalctl -u langflow --since "72 hours ago"
ss -tulpn | grep 7860

How urgent is it for you?

For an exposed or lightly protected instance, this is a same-day job: patch, rotate, review. For an internal-only deployment behind SSO and network controls the exposure drops, but I would still not sit on it, exploitation is browser-mediated, so one authenticated user opening one malicious page is the whole prerequisite.

References & Further Reading

Frequently Asked Questions

What is CVE-2025-34291?

It is a critical (CVSS 9.4) chained vulnerability in Langflow ≤ 1.6.9. Permissive CORS (allow_origins='*' with allow_credentials=True) combined with a SameSite=None refresh-token cookie lets a malicious origin steal a victim's tokens and reach authenticated endpoints, including built-in code execution, resulting in account takeover and remote code execution.

How do I fix it?

Upgrade Langflow to a version above 1.6.9 (pip install --upgrade langflow or pull the updated container image), then rotate all secrets the instance stored, review token-refresh and access logs for abuse, and stop exposing Langflow directly to the internet, front it with SSO and a Zero Trust proxy and enforce strict, non-wildcard CORS.

We only run Langflow internally. Are we safe?

Lower risk, but not zero. Because exploitation is browser-mediated, an authenticated user visiting a malicious web page can trigger the cross-origin token theft. Patch promptly even for internal deployments, and restrict access with SSO and network controls.

What I'd take away from this one

CVE-2025-34291 is a CORS-plus-cookie misconfiguration with an outsized blast radius, purely because of what Langflow holds. Patch above 1.6.9, rotate the secrets, get it behind SSO, and pin your allowed origins. The wider lesson I keep relearning: the AI tooling in most environments got stood up in an afternoon and secured never, and it is worth spending a day finding all of it before the next advisory does it for you.