Langflow's Unauthenticated RCE Is a Live KEV Entry (CVE-2026-0770)

Someone on your team stood up Langflow a few months ago to prototype an internal assistant, pointed it at a spare VM so a colleague could click through the demo, and moved on. As of this week, CISA is telling federal agencies that a box like that one is running an attacker's code as root. The same message applies to everyone else who left a Langflow instance reachable.

CVE-2026-0770 is an unauthenticated remote code execution flaw in Langflow, the open-source visual builder teams use to wire up LLM agents and workflows. Trend Micro's Zero Day Initiative rates it CVSS 9.8: network vector, low complexity, no privileges, no user interaction. It affects Langflow versions up to and including 1.7.3, and the fix landed in Langflow 1.9.0. On July 21 it was added to the CISA Known Exploited Vulnerabilities catalog with a federal remediation deadline of July 25 - today.

What has already happened to exposed instances

This is not a theoretical proof of concept sitting on a researcher's blog. According to reporting on the CISA order, exploitation intelligence firm KEVIntel first saw CVE-2026-0770 hit in the wild on June 27, and logged more than 220 exploitation attempts from 64 unique source IP addresses before the vulnerability was even KEV-listed. The payloads were not subtle. They ran command-execution and system-reconnaissance checks, pulled down second-stage scripts, and reached for environment variables, cloud metadata, and credential files.

That last part is the detail that should decide your morning. An exposed Langflow box is almost never just a Langflow box. It holds the API keys for whatever model provider it calls, it usually runs on a cloud instance with an IAM role, and it can hit 169.254.169.254 for instance credentials the moment code runs on it. The attack pattern here treats your AI prototype as the front door and your cloud account as the destination.

Whether this one is yours

Here is the honest relevance verdict. If nobody in your organization has ever run Langflow - not in production, not in a data-science sandbox, not in a container someone spun up for a hackathon - then CVE-2026-0770 is not your emergency, and you can move it to the "confirm and close" pile. That is a real and useful answer, and most SMBs can reach it in a few minutes.

The problem is confirming the negative. Self-hosted AI tooling is where shadow IT has quietly moved. In my experience the exposed instance is rarely in the asset inventory, because it was never a sanctioned service - it was a quick experiment that got a public IP for a demo and never got torn down. If you run any kind of data or ML function, if you have developers with cloud credentials, or if an MSP client of yours does, you owe yourself the check below before you decide this does not apply. Assume it might, until a scan says otherwise.

The bug is Python exec on attacker input

Langflow's job is to turn a visual flow into running Python, so it has always had code paths that compile and execute user-supplied snippets. CVE-2026-0770 lives in the code-validation endpoint, /api/v1/validate/code, which mishandles an exec_globals parameter and passes attacker-controlled input into Python's exec(). Because that endpoint answers without authentication on a default install, anyone who can reach the port gets code execution in the context of the process, which in most container images is root.

This is the same weakness class that produced the earlier Langflow RCE, CVE-2025-3248, and it is not the only exec-based path. A sibling advisory, GHSA-vwmf-pq79-vjvx (CVE-2026-33017), covers a public flow-build endpoint that executes attacker-supplied node code during graph construction, before a flow is ever "run." Both are fixed in 1.9.0. The lesson for defenders is that Langflow's design executes code by intent, so exposure of the web interface to any untrusted network is the exploitable condition, independent of which specific endpoint is patched this month.

Find out if you are exposed in five minutes

Langflow listens on port 7860 by default. You are looking for two things: instances reachable from the internet, and instances reachable from any network segment an attacker could pivot through. Fingerprint the version endpoint, then sweep your own ranges for the default port.

# Fingerprint a suspected Langflow host (a live instance answers /api/v1/version).
# Anything at or below 1.7.3 is vulnerable to CVE-2026-0770.
curl -sk https://TARGET:7860/api/v1/version

# Sweep internal ranges for the default Langflow port and grab the service banner.
nmap -p 7860 -sV --open 10.0.0.0/8 192.168.0.0/16 2>/dev/null | grep -B4 -iE '7860|langflow'

# For anything cloud-hosted, check external exposure from the outside in.
# A Langflow login/version page answering from a public IP is the finding.
curl -sk -o /dev/null -w '%{http_code}\n' https://YOUR_PUBLIC_IP:7860/

For hosts you manage directly, do not rely on a network sweep alone - a container can be listening on a port your scanner never reaches. On any Docker or Kubernetes host used by a data or dev team, list the running images and grep for the tell-tale process and port.

# Find Langflow containers and the port they publish on a Docker host.
docker ps --format '{{.Image}}\t{{.Ports}}' | grep -iE 'langflow|7860'

# On the host directly: is the uvicorn worker bound to 0.0.0.0 (all interfaces)?
ss -ltnp | grep -E ':7860'

Do not stop at the internet edge. A Langflow instance bound to an internal IP is still exploitable by anything that lands on that subnet - a phished workstation, a compromised CI runner, a foothold in another container. A worker bound to 0.0.0.0 rather than 127.0.0.1 is reachable from the whole segment. Treat internal reachability as exposure, not safety.

Hunt for the compromise you may already have

Exploitation started in late June, so "we will patch it this week" is not the same as "we were not hit." If you find a vulnerable instance, assume it was probed and look for evidence before you rebuild. Start with the request logs on the box or its reverse proxy, then look for the outbound behavior the payloads exhibited.

# Reverse-proxy / access-log hunt: unauthenticated POSTs to the validate endpoint.
grep -E 'POST[[:space:]]+/api/v1/(validate/code|build_public_tmp)' \
  /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# The tell that a payload actually ran: outbound hits to cloud metadata.
grep -F '169.254.169.254' /var/log/langflow/*.log /var/log/syslog 2>/dev/null

# Unexpected children of the Langflow / uvicorn process (curl, sh, python one-liners).
ps -eo pid,ppid,user,cmd | grep -iE 'uvicorn|langflow' | grep -vE 'grep'

Any hit on the metadata address, any unexpected shell spawned by the app process, or any burst of validate-endpoint POSTs from unfamiliar IPs is enough to treat the host as compromised and move to credential rotation. While you are on the box, check the usual persistence spots a second-stage script would touch: new or modified entries in crontab -l and /etc/cron.*, unfamiliar systemd units, and additions to ~/.ssh/authorized_keys for the service account. A quiet cron job that re-fetches a payload every ten minutes is how a one-time RCE becomes a permanent tenant.

Contain the box, then rotate what it could reach

The clean fix is to upgrade to Langflow 1.9.0. If you cannot patch in the next few hours, cut the exposure another way in the meantime:

• Take the interface off any untrusted network. Bind it to localhost, or put it behind an authenticating reverse proxy or VPN so the endpoint is not reachable without a credential.
• Block egress to 169.254.169.254 from the host, and enforce IMDSv2 with a hop limit of 1 on AWS so a compromised process cannot mint instance credentials.
• Run the service as an unprivileged user in a locked-down container, not as root, so code execution does not immediately mean host takeover.

If the box was exposed at any point since late June, patching is only half the job. Rotate every secret it could touch: the model-provider API keys in its environment, any database credentials, and the cloud IAM role or access keys attached to the instance. The reported payloads went after exactly those, so treat them as burned until proven otherwise. In AWS, filter CloudTrail for the instance role's session name and look for calls it never normally makes - sts:GetCallerIdentity from an outside IP, s3:ListBuckets, or IAM enumeration are common first moves once a role is stolen. In Azure or GCP, pull the equivalent sign-in and activity logs for the managed identity. If you cannot rule out use, revoke and reissue rather than wait for certainty.

Take Langflow off the internet, then rotate what it could reach

The move for the next few hours is narrow and concrete: inventory every Langflow instance you or your clients run, upgrade the vulnerable ones to 1.9.0, and pull any that answer from a public IP behind authentication today. Then rotate the credentials those boxes could reach and read back the audit logs. Self-hosted AI tools ship with code execution as a feature and a web server that is happy to listen on every interface, so they belong on the same patch-and-exposure cadence as any other internet-facing application - not in the unmanaged corner where prototypes go to be forgotten. If you want a second set of eyes on where your AI tooling actually sits on your perimeter, that is the kind of external attack-surface review we do at Red Hound.