2 SEP 2026 — VulnCheck reports 360 attacks on CVE-2026-0768, an unauthenticated remote code execution flaw in Langflow's custom component editor, used to harvest AWS secrets and OpenAI API keys from environment variables. It is the sixth separately identified Langflow flaw exploited in 2026. At that count the vulnerability is no longer the story.
The flaw and the numbers
CVE-2026-0768, rated critical, affects Langflow 1.4.2 and earlier and was fixed in 1.11.6. The flaw sits in the custom component editor's code validator, which fails to validate a user-supplied string before executing it as Python.
Attackers query environment variables to harvest administrative credentials, Langflow superuser authentication keys, AWS secrets and OpenAI API keys. They have also been observed reading `/root/.cache/langflow/secret_key`, obtaining SSH access and reading bash history.
VulnCheck recorded at least 50 exploitation attempts against UK honeypots over one weekend, rising to 360 observed attacks by 1 September. The traffic originates primarily from Russia. There is no known public proof of concept. The flaw was disclosed in January 2026.
Six in one year is a pattern, not a run of bad luck
The exploited Langflow flaws of 2026 are CVE-2026-33017, CVE-2026-5027, CVE-2026-55255, CVE-2026-0770, CVE-2026-9198 and now CVE-2026-0768. One of them made Langflow the first AI agent platform on the US government's known exploited vulnerabilities list.
A product with that record has a structural problem, not a series of coding mistakes. The problem is the feature. Langflow lets a user write a custom component containing Python, and then runs it. Executing user-supplied code is not a bug in the product; it is the product.
Every fix in this sequence narrows a validator standing between an input and an interpreter. Getting that validator right every time is difficult; an attacker only needs to find one way through. Sandboxing an interpreter properly is a specialist problem that browser vendors employ teams to work on continuously.
A January flaw being exploited in September says something specific
This CVE was disclosed and fixed in January. The attacks are landing now, against instances running 1.4.2 or earlier, months after 1.11.6 was available.
The advice here is not about this specific vulnerability. It is about the substantial, internet-discoverable population of Langflow deployments that have not been updated since at least January.
Which is the ordinary shape of self-hosted developer tooling. Something is stood up for a project, it works, nobody owns it, and it stays on the version it was installed with. The tool is running with credentials in its environment the entire time.
No public exploit, 360 attacks
The two facts, high-volume attacks and no public exploit, seem contradictory. Exploitation at this volume normally follows a published proof of concept, because that is what turns a vulnerability into a commodity.
Here there is none, and the attacks are arriving anyway, largely from one origin. That points to a smaller number of operators working from the patch rather than from someone else's exploit — which is not difficult when the fix is a validator change in an open-source repository, and the diff shows precisely what was permitted before.
This reverses a common assumption. Teams often deprioritise a flaw when no public exploit exists. For open-source software that reasoning is weak; the patch itself is the exploit specification, published the moment the fix ships.
Environment variables are the actual loss
The code execution is the entry. What leaves is whatever the process could read, and for an agent-building platform that is by design a set of provider credentials.
A Langflow instance needs an OpenAI key to call a model, AWS credentials to reach storage, and often database and vector-store credentials as well. All of them sit in the environment because that is how every deployment guide says to supply them, and a process that can execute Python can read its own environment without any further exploitation.
The blast radius is not the Langflow host; it is every service those credentials can reach. The attacker now holds valid keys rather than an exploit, so nothing they do next will look like an attack in any log.
What to do, in order
Find the instances first. Self-hosted agent tooling is rarely in the asset inventory, and the reliable ways to find it are certificate transparency entries for your domains, a scan of your own external ranges, and a look at what has been granted API keys in your model provider's console.
Then rotate before patching. If an instance was running a vulnerable version and reachable, treat every credential in its environment as disclosed — model provider keys, cloud access keys, database passwords, the Langflow secret key — because patching a compromised host leaves the attacker holding everything they already took.
Then move the credentials out of the environment entirely, into a secrets manager the application requests at use time, so that code execution on the host yields a request that can be revoked rather than a set of keys that cannot. We reported when Langflow became the first AI agent platform on the US exploited-vulnerability list. Five CVEs later, the answer is not to patch faster but to decide whether this belongs on an internet-facing host at all.
View author profile → · Editorial policy
