Langflow's code-validation endpoint just produced its second unauthenticated RCE

Point a code-execution endpoint at the open internet, let it run whatever payload arrives, and skip the login check, and you have not shipped a bug. You have shipped a feature that behaves like a bug forever. Langflow, the popular visual builder for stringing together AI agents, has now proved the point twice. On July 21 CISA added CVE-2026-0770, a fresh unauthenticated remote code execution flaw in Langflow's code-validation surface, to its Known Exploited Vulnerabilities catalog. It is the second critical, root-level, no-login RCE in that same corner of the product in fourteen months. If you run Langflow anywhere reachable, the patch is the easy half of the job.

The flaw sits in Langflow's validate endpoint, in how it handles the exec_globals parameter. CISA files it under "Inclusion of Functionality from Untrusted Control Sphere," which is the catalog's polite phrase for "the server runs code the caller supplies." No credentials are required. A single crafted request executes arbitrary code with root privileges on the host. Security Affairs puts the CVSS at 9.8. The bug surfaced through Trend Micro's Zero Day Initiative, and by the time CISA acted, KEVIntel telemetry had counted more than 220 exploitation attempts from 64 distinct source addresses, chasing AWS keys, environment variables, and container metadata. Federal civilian agencies were given until July 24 under Binding Operational Directive 26-04, one of the shortest KEV deadlines you will see. Treat that three-day clock as a statement about how live this is, not a government formality.

This is the same door, opened again

The detail that should change how you think about Langflow is not this one CVE. It is the repetition. In May 2025, CVE-2025-3248 put Langflow's /api/v1/validate/code endpoint on the KEV list for exactly this shape of problem: unauthenticated, CVSS 9.8, arbitrary code execution in versions before 1.3.0. A year later, the validate surface produced CVE-2026-0770, same severity, same no-auth root execution. Whether 0770 is a regression of the 2025 fix or a parallel path into the same feature, the operational conclusion is identical: the code-validation endpoint is a recurring liability, not a one-time mistake you patch and forget. Add the file-read-to-RCE chain we wrote up in June (CVE-2026-55447, CVSS 9.6), and that is three separate routes to code execution on a Langflow host inside a single year. A platform whose job is to run model-driven logic keeps handing strangers the ability to run their own.

The kill chain past this bug is already built

The reason 64 IPs are hammering exposed instances is that the payoff is documented. Sysdig watched a threat operator it tracks as JADEPUFFER take the earlier validate RCE, locate /var/run/docker.sock on the compromised box, and escape the container to host root, then deploy ENCFORGE, a compiled Go ransomware built specifically for AI shops. It scrambles the artifacts an AI shop cannot cheaply regenerate: trained weights, the vector stores that back retrieval, the datasets behind them, and about 180 file types in all, from PyTorch checkpoints to SafeTensors, GGUF models, and FAISS stores, each renamed with a .locked suffix. We covered that AI-native extortion pattern in "AI-agent ransomware is making Langflow break-ins unrecoverable". CVE-2026-0770 does not start a new story. It hands the crews already running that playbook a fresh, unauthenticated front door, and the automation to walk from a single request to encrypted model artifacts is off the shelf.

The patch is necessary and not sufficient

Here is the part the KEV listing will not tell you. Upgrading closes CVE-2026-0770, but it does nothing about the design assumption underneath every one of these flaws: Langflow, like most AI-agent builders, ships code-evaluation endpoints as a headline feature and expects to run on a trusted network. The moment such an instance is internet-reachable, "run arbitrary code" is one parsing mistake away by definition, and the history says the next mistake is coming. The 64 scanning addresses are not guessing; they are enumerating instances that should never have had a public address. So patch, but also decide that the Langflow control plane is a code-execution service and give it the blast radius of one.

Contain it now

• Upgrade to the current Langflow release that fixes CVE-2026-0770, and confirm the running build rather than trusting the container tag. If you cannot patch today, take the instance off any public interface first.
• Put the control plane behind authentication and a reverse proxy or VPN. A Langflow that answers unauthenticated requests from the internet is exploitable regardless of version.
• Watch for POSTs to the validate endpoints and for exec_globals in request bodies. In your SIEM, alert on those hitting a Langflow host from outside your network.
• Alert on the post-exploitation tells from the known chain: access to /var/run/docker.sock from a Langflow process, and unexpected outbound image pulls or container launches.
• Rotate any AWS keys, tokens, or secrets reachable from the Langflow container. The active exploitation is credential-hunting, so assume anything the process could read is a target.
• Segment the model store. ENCFORGE goes straight for weights and vector indexes, so keep versioned, offline copies that a host-root attacker cannot reach or encrypt.

Langflow is not uniquely careless here, and that is the uncomfortable part. The whole class of self-hosted AI-orchestration tools trades a code-execution surface for developer convenience. CVE-2026-0770 is a reminder to price that trade honestly: assume the endpoint will be exploitable again, and build the network around it so the next unauthenticated RCE is contained instead of catastrophic.