Attackers exploit CVE-2026-0768 in Langflow to siphon OpenAI and AWS keys

September 1, 2026. BleepingComputer reports that CVE-2026-0768, an unauthenticated remote code execution flaw in Langflow, is being exploited in the wild to steal credentials. 360. That is the total number of exploitation attempts counted by VulnCheck’s honeypots, which saw 50 over the weekend alone. 1.4.2. That is the last vulnerable version. Why it matters: Langflow has become the most-hammered target in the self-hosted AI infrastructure space, with six flaws exploited since January 2026.

The flaw: a code validator that executes instead of checking

Langflow is an open-source Python framework with a low-code GUI used to build AI applications, agents, chatbots, and RAG pipelines by wiring together components — language models, prompts, databases, APIs. The CVE-2026-0768 flaw sits in the validator of the custom component editor: the code parameter sent to the validation endpoint is handled without checks before being executed as Python code. The result is that a single unauthenticated request is enough to run arbitrary commands with the process privileges.

The flaw was disclosed in January 2026, referenced by Trend Micro Zero Day Initiative as ZDI-26-034, and affects Langflow up to and including version 1.4.2. It is rated critical. The nature of the breach — unauthenticated execution, running as root inside the container in many deployments — explains why attackers find it so appealing: one payload is enough to take over the whole instance.

What attackers harvest, precisely

Caitlin Condon, lead researcher at VulnCheck, detailed the observed behavior. The exploitation requests query environment variables to extract administrative credentials: LANGFLOW_SUPERUSER, OpenAI keys (OPENAI_API_*), and AWS secrets (AWS_ACCESS_*, AWS_SECRET_*). Attackers also read /root/.cache/langflow/secret_key, check SSH access, and measure the .bash_history size — a precise catalog of everything valuable a Langflow instance holds.

The traffic originates mostly from Russia and targets VulnCheck’s honeypots in the United Kingdom. No public proof of concept has been identified yet, which did not stop the escalation: the counter moved from 50 to 360 attempts within days. That is the classic pattern of a January flaw finding its audience once the exploit gets industrialized.

The sixth exploited flaw in eight months

CVE-2026-0768 is not an isolated accident: it is the sixth Langflow flaw exploited in 2026. In March, CVE-2026-33017, a critical code-injection flaw, was exploited within a day of disclosure to run Python scripts and steal .env and database files. It was followed by CVE-2026-5027 (path traversal to write arbitrary files), CVE-2026-55255 (an authentication bypass granting access to other users’ workflows), CVE-2026-0770 (root command execution), then CVE-2026-9198, which CISA flagged as exploited after several proofs of concept went public.

The series paints a clear profile: Langflow concentrates the properties that attract AI-infrastructure attackers — a simple deployment that often ends up exposed by default, cloud and model-provider credentials stored in plaintext in the environment, and a user base that prioritizes fast setup over hardening. Every patch opens a new cycle of hunting for the next flaw.

The full list of exploited flaws fits in a table, and it deserves to be shown as-is to measure the scale:

The common thread across these six flaws is profitability: each turns an exposed instance into a credential-collection point that then grants access to the cloud or the model provider. It is a two-stage theft — first the machine, then everything it was allowed to call.

What to do right now

Langflow’s recommendation is unambiguous: upgrade to version 1.11.6, which fixes all known flaws in the tool. For a team already running it, the version check and exposure detection fit in a couple of commands:

# Check the installed version (vulnerable: <= 1.4.2; fixed: >= 1.11.6)
pip show langflow | grep -i version

# Confirm no instance is reachable from the Internet
curl -sS --max-time 5 http://LANGFLOW-HOST:7860/api/v1/version || echo "not exposed"

But the upgrade alone is not enough. An instance that ran a vulnerable version may have had its environment variables read: treat the secrets as compromised and rotate them — OpenAI keys, AWS access keys, the LANGFLOW_SUPERUSER credentials, and the cache signing key. Rotation is the part teams forget, yet it is the step that neutralizes the harvest already collected.

Why a January flaw explodes in September

CVE-2026-0768 was disclosed in January and only mass-exploited eight months later. That gap between a public advisory and industrialized exploitation is the real window to watch, and it is shorter for self-hosted AI frameworks than for enterprise software: there is no forced-update channel, and the instance that gets pillaged is the one whose changelog nobody reads. The corollary is that a late patch does not protect against the harvest already collected, hence key rotation.

How to detect an already-compromised instance

The flaw sits inside a broader shift: the frameworks used to build AI applications — Langflow, but also Dify, Flowise, or n8n — inherently store model-provider and cloud credentials, which makes them higher-value targets than ordinary web applications. Stealing a database yields data; stealing a Langflow instance yields the keys that open the rest of the infrastructure.

Upgrading to 1.11.6 closes the breach but says nothing about what already happened. The first step is to inventory what the instance exposes in its environment, since that is exactly what attackers read:

# What the attacker could read: list the container's sensitive variables
docker exec <langflow> env | grep -Ei 'OPENAI|AWS|SUPERUSER|SECRET|TOKEN'

# The cache signing key: check its existence and last-read timestamp
ls -la /root/.cache/langflow/secret_key

If the OPENAI_API_KEY, AWS_ACCESS_KEY_ID, or LANGFLOW_SUPERUSER variables are present, assume they are compromised: rotate them immediately, before you even patch. Also watch the container’s outbound traffic — exfiltration to an unusual endpoint is the most direct sign of a successful exploit. Finally, check SSH access and the .bash_history file: the observed requests were precisely trying to assess those two surfaces to prepare persistence.

The order of operations matters: rotate secrets first, patch second, then monitor. Reversing the two leaves a window where already-stolen keys remain usable while you believe the problem is solved.

Set a baseline now, not after the next advisory. Log the /api/v1/validate endpoint, alert on any call that does not originate from your CI or your internal network, and keep an up-to-date list of every Langflow instance and the keys it can reach. The lesson of six exploited flaws in eight months is that the next one is already being written; the only question is whether your instance is patched and its keys rotated before it is found. And because most of the current traffic is automated scanning rather than targeted intrusion, detection is an access-log grep rather than a forensic investigation.

Verdict

If you expose Langflow to the Internet, stop: this framework is not meant to be publicly reachable. Put it behind an authenticated reverse proxy, or restrict it to an internal network, regardless of version.

If you use it internally, upgrade to 1.11.6, then rotate every secret that may have lingered on a vulnerable instance. A software fix without key rotation closes only half the risk.

If you do not use Langflow, take the generic lesson: self-hosted AI frameworks store model-provider and cloud credentials, which makes them high-value targets. Inventory the ones your teams have deployed, check their exposure, and hold them to the same patch discipline as your production services.

References

• Critical Langflow flaw exploited to steal OpenAI and AWS keys — BleepingComputer, September 1, 2026
• CVE-2026-0768 — NVD
• ZDI-26-034 — Trend Micro Zero Day Initiative