Langflow CVE-2026-0768 — unauthenticated validate-endpoint code injection (CVSS 9.8) mass-exploited to steal OpenAI/AWS keys

View raw markdownEdit on GitHub ↗

TL;DR

CVE-2026-0768 is an unauthenticated remote code execution flaw in Langflow's custom-component editor: the validate endpoint takes a user-supplied string and runs it as Python without checking it first, so an attacker who can reach the API executes code as root (CVSS 9.8, CWE-94). Trend Research reported it to the vendor on 2025-07-18; the Zero Day Initiative published it as a 0-day advisory on 2026-01-09 after notifying the vendor of intent to publish; NVD listed it 2026-01-23 against Langflow 1.4.2. Nothing happened for seven months. Then on 2026-08-30 VulnCheck's canaries logged 50+ exploitation attempts within hours, rising to 360 by 2026-09-01 — with post-exploitation commands that read LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS*/AWS_SECRET*, the Langflow secret-key file, .ssh, and .bash_history. This is, per The Hacker News' count, Langflow's twelfth exploited CVE since 2025. If Langflow is reachable from the internet, assume every key in its environment is gone.

What happened

ZDI's advisory (ZDI-26-034, credited to Peter Girnus, William Gamazo Sanchez, and Alfredo Oliveira of Trend Research) describes the bug plainly: the code parameter handed to the validate endpoint is executed as Python with no validation of the string, and no authentication is required. The timeline on ZDI's page — reported 2025-07-18, vendor notified of intent to publish as a 0-day on 2025-12-10, published 2026-01-09 — is the coordinated-disclosure clock running out with no fix recorded on the advisory. NVD's record, published 2026-01-23, carries the 9.8 score and lists 1.4.2 as the affected version. Neither source states a fixed version, and this sweep did not find a vendor advisory naming one; see "Am I affected?" for how to reason about that.

Exploitation, when it came, was fast and credential-focused. VulnCheck (reported by The Hacker News on 2026-09-01 and Security Affairs on 2026-09-02) saw the first wave on 2026-08-30: more than 50 detections in a few hours, 360 by the following Monday, most traffic from Russia, with UK-based systems among the targets. The attackers' first moves after code execution were reconnaissance for credentials, not persistence: environment variables for the Langflow superuser account and for OpenAI and AWS, /root/.cache/langflow/secret_key, SSH access, and the size of .bash_history. Subsequent payloads included credential harvesters, proxy agents, SimpleHelp remote-access software, and XMR miners. The same campaign hit Ruby on Rails' Active Storage (CVE-2026-66066, "KindaRails2Shell") for secret_key_base, master keys, and database and cloud-storage credentials — the attacker is collecting keys, and AI frameworks are where the most expensive keys live.

How this relates to the Langflow CVEs already tracked here. Langflow's validate endpoint has been a repeat offender: CVE-2025-3248 was the 2025 validate-endpoint RCE that JadePuffer and the Hermes-agent scanning campaign exploited, and CVE-2026-33017, CVE-2026-55255, and CVE-2026-9198 each got their own file. CVE-2026-0768 is a distinct CVE with its own ZDI case; ZDI's advisory does not describe it as a bypass of an earlier fix, so this repo does not either. What is shared is the lesson every prior Langflow entry ends on: the authentication gate is the only thing that has reliably stopped these.

Am I affected?

You are exposed if you run Langflow 1.4.2 or earlier anywhere an attacker can reach the API. Because neither ZDI nor NVD names a fixed version, treat "later than 1.4.2" as probably fixed and confirm against the vendor's current release notes — this repo's CVE-2026-33017 entry is the precedent for a Langflow "fix" that needed a second release.

pip show langflow 2>/dev/null | grep -i version
docker ps --format '{{.Image}}' | grep -i langflow
# Is the API reachable off-box?
ss -tlnp | grep -i '7860\|langflow'
# Post-exploitation signals reported by VulnCheck — check your instance's shell history and process list
grep -E 'OPENAI_API|AWS_(ACCESS|SECRET)|LANGFLOW_SUPERUSER|secret_key' /root/.bash_history 2>/dev/null
ls -la /root/.cache/langflow/secret_key 2>/dev/null
ps aux | grep -iE 'simplehelp|xmrig|minerd' | grep -v grep

If Langflow was internet-reachable on 2026-08-30 or later with auto_login on or no auth in front of it, assume compromise regardless of what the logs show — the reconnaissance commands are one-shot reads.

If you are affected

  1. Take the instance off the network. Upgrade to the current Langflow release and put authentication in front of it — the Unit 42 agentic-scanning case documented an autonomous attacker holding a working Langflow exploit that failed because auth was on.
  2. Rotate everything the process could read: playbooks/rotating-cloud-credentials.md — OpenAI keys, AWS keys, the Langflow superuser password and secret key, and any SSH key on the host.
  3. Treat the host as compromised, not just the app: playbooks/if-your-webapp-was-compromised.md. The miners and remote-access tools are the visible payloads.

Prevention

  • prevention/credential-hygiene.md — an AI framework's environment is a key ring. Short-lived, scoped credentials; nothing in /root/.bash_history.
  • prevention/agent-sandboxing.md — an app whose feature is "run user-supplied Python" should not run as root, and should not be reachable from the internet without a login. Twelve exploited CVEs in one product is not a patch-cadence problem; it is a deployment-model problem.
  • Subscribe to the KEV feed for the products in your stack. Langflow CVEs have gone from advisory to exploitation in 20 hours (CVE-2026-33017) and, here, sat quietly for seven months before a mass campaign — the two cases argue for the same thing, which is not exposing the API at all.

Sources