Langflow's auto-login default gives any stranger admin, then RCE

When Langflow's maintainers locked the code-execution endpoint behind a login last year, the fix rested on one assumption: that a stranger could not get a login. CVE-2026-9198 is the proof that they can. The flaw chains two of Langflow's own API endpoints. One hands any unauthenticated caller a superuser token on request. The other runs the Python you send it. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on August 4, 2026, with a three-day federal patch deadline of August 7. If you self-host Langflow, the safe assumption for an internet-facing instance is that it is already running someone else's code.

Langflow is a widely used open-source tool for building AI agent and retrieval workflows visually. Because a flow is code that runs on the server, the product's control plane has a large and dangerous attack surface, and this is the fifth time in roughly a year that surface has produced a critical vulnerability we have written up.

How auto-login becomes remote code execution

The chain is two requests. The first hits /api/v1/auto_login, an endpoint that mints a SUPERUSER token for any network caller without authentication. The second sends attacker-supplied Python to /api/v1/validate/code, which the server evaluates in-process with exec(). The result is arbitrary code execution as a privileged Langflow user, which on a default deployment means full control of the host process and everything it can read. The weakness is classified as CWE-94, code injection, and carries a CVSS score of 9.8. CISA lists the affected product as IBM Langflow and the affected range as every release from 1.0.0 up to and including 1.10.0, with the fix in a build above 1.10.0.

This is a defender's briefing, not a recipe, so no payload appears here. The mechanism matters because it tells you what to switch off, not how to attack anyone. The critical detail is that the second endpoint requires a token, and the first endpoint gives that token to anyone who asks.

Why last year's patch did not hold

We covered the second unauthenticated RCE in the same validate endpoint in July and could not tell from outside whether the earlier fix had quietly regressed or a new path had reached the same feature. CVE-2026-9198 settles it, and the answer is worse than either guess. Somewhere in the response to earlier bugs, the code-validation endpoint was put behind a token check. That check does nothing on a default install, because auto_login is enabled by default and hands out superuser tokens to unauthenticated callers. Requiring a token added no protection when a sibling endpoint mints tokens for free. The gate was closed and the key was left in a bowl by the door.

The pattern is now a straight line. In May 2025, CVE-2025-3248 put the validate endpoint on the KEV list. In July 2026, CVE-2026-0770 did it again at the same severity. A separate rigged-document flaw (CVE-2026-55447) reached code execution through the file reader, and an access-control bug (CVE-2026-55255) let one account run another's flows. A product whose job is to run model-driven logic keeps handing strangers the ability to run their own.

There is a sharper reason to move fast on this one. When we wrote about an autonomous AI agent that scanned 84 exposed Langflow hosts and failed to compromise a single one, the reason it failed was precise: the bug it was using needed auto_login already enabled or a known public flow ID, and the internet-facing hosts did not hand those over. CVE-2026-9198 removes that barrier. The token is no longer a precondition an attacker has to get lucky on. The auto_login endpoint supplies it. The class of exposed host that was safe by accident last month is not safe this month.

How to know if you were hit

Start by not trusting the risk scores. At the time of writing, at least one major vulnerability database still shows this CVE with a low exploit-probability score and a "not known exploited" flag, while CISA has it on the KEV list with a federal deadline. CISA adds an entry to KEV only when it has evidence of exploitation in the wild, so the KEV listing is the signal and the aggregator score is lagging it. A team that gates patch priority on a probability percentile is already behind on this one. Treat the KEV listing as today's work.

For detection, the request pattern is distinctive because the attack needs both endpoints in sequence. Watch your Langflow access logs and reverse proxy for a call to /api/v1/auto_login followed shortly by a POST to /api/v1/validate/code from the same source. Post-compromise, the strongest signal is behavioral: the Langflow interpreter process spawning child processes it has no reason to spawn, such as sh, bash, curl, wget, or python -c. If you have that on an exposed instance, assume execution succeeded and move to incident response, including rotating any credentials the container could read. The ransomware built for exactly this foothold encrypts model weights and vector stores that are often nowhere in a backup plan, so the cost of a missed detection here is high.

Turn off auto-login before you patch

Upgrading past 1.10.0 is the fix, but it is not the fastest risk reduction, and it is not sufficient on its own. Do these in order. First, set LANGFLOW_AUTO_LOGIN=false, which closes the token-minting endpoint immediately without waiting for a deployment window. Second, take the control plane off any public interface: bind it to 127.0.0.1 or put it behind an authenticating reverse proxy or a VPN. Third, upgrade to a release above 1.10.0 and confirm the running build.

One point of exposure translation before you decide this is only an internet problem. The auto_login endpoint mints a token for any network caller, not just a caller from the public internet. A Langflow instance reachable only on an internal VLAN or a VPN still hands a superuser token to anyone who reaches that network. Internal exposure is internal remote code execution. Segment it and authenticate it; do not settle for keeping it off the open internet. For the ongoing job of finding which of your hosts run affected builds and tracking KEV entries against your fleet, that is what vulnerability detection is for.