The AI-agent builder that runs a stranger's code: CVE-2026-0770 in Langflow

A tool that runs code by design

Langflow exists to build — by dragging blocks on a canvas — the flows and agents that orchestrate language models. To do that it has to run pieces of user-written logic: that's the job. The problem starts when the door to that execution is left open to anyone, without the wall that should separate it from the outside world.

That is exactly what CVE-2026-0770 describes. The function whose name promises a check — validate_code(), in src/lfx/src/lfx/custom/validate.py — instead of merely inspecting the supplied code passes it straight to exec(), the Python executor, with no sandbox. What was meant to be validation is, in effect, execution.

1. 01
   Request to the /validate endpoint

   unauthenticated attacker
2. 02
   exec_globals parameter / validate_code()

   user-supplied Python code
3. 03
   exec() with no sandbox

   arbitrary execution on the server

Why the score is near the ceiling

The CVE carries a CVSS 9.8 (critical), and the two factors pushing it that high are the same ones that make a flaw an operational nightmare: no authentication required and code execution as the result. No account, no victim interaction; just reach an exposed Langflow instance over the network and send a request to the validation endpoint.

The defect falls under "inclusion of functionality from an untrusted control sphere": the server accepts and runs logic that arrives from outside as if it were its own. In practice, for the attacker, the validation endpoint becomes a shell.

Actually exploited, not just theoretical

On 21 July 2026 CISA added CVE-2026-0770 to the Known Exploited Vulnerabilities catalog, in the same batch of four that also included the two WordPress Core flaws. Entry into KEV is the signal that matters: this is not a "potentially dangerous" CVE, it is one someone is using.

Compounding the picture, multiple public proof-of-concepts for this flaw are already on GitHub. When the exploit is a git clone away and the target is a tool meant for fast prototyping — so often installed on the fly, sometimes left reachable without a reverse proxy authenticating in front — the practical barrier for an opportunistic attacker collapses.

In fairness, what is not confirmed: there is no attributed group and no named campaign. The consistent scenario is opportunistic exploitation of exposed instances, not a targeted operation. Exact affected versions and the number of hit instances should be read off the primary sources (the GitHub advisory and CVE trackers) as they settle, not taken as final here.

What to do

Three moves, in order of urgency. First: update Langflow to the version that removes the unprotected execution, following the official advisory (GHSA-g22f-v6f7-2hrh) for the fixed release. Second, and often more important right now: take the instance off direct exposure to the internet. A development tool like this has no reason to be publicly reachable; putting it behind a VPN or an authenticating proxy shrinks the surface regardless of the patch. Third, on instances that may have been reached, look for signs of anomalous execution — unexpected Python processes, outbound connections, files left on the system — because with an unauthenticated RCE already in KEV, the prudent working assumption is that an exposed, unpatched instance should be treated as compromised until proven otherwise.