Attackers began exploiting an unauthenticated code execution flaw in Langflow, the open-source visual builder for LLM and agent workflows, on August 30, 2026. VulnCheck logged more than fifty attempts within hours and 360 by the following day, with source traffic it described as primarily originating from Russia. That is the news, and it is the least interesting part. The Langflow vulnerability currently being exploited is at least the fourth of its exact shape in that product in eighteen months, and the requests attackers send once they are in are not trying to take over the machine. They are reading environment variables named for model provider and cloud credentials. This piece covers what the flaw actually is, why the same bug keeps shipping, what the observed requests go looking for, why the key is worth more than the host, the two documented precedents in adjacent products, why these systems end up reachable at all, and what to do if you run one.
The short version: a category of software that exists to hold credentials for expensive external services has been shipping unauthenticated code execution roughly quarterly, and most teams still classify it as an internal developer tool rather than as a secrets store.
What the current Langflow vulnerability actually is
The mechanism is worth understanding precisely, because it is not a parsing bug or an injection flaw in the usual sense.
Langflow lets you write custom Python components, and it validates them by running them. Trend Micro’s Zero Day Initiative, which disclosed the issue as ZDI-26-034, describes the flaw as existing "within the handling of the code parameter provided to the validate endpoint," where "the issue results from the lack of proper validation of a user-supplied string before using it to execute Python code." The sentence that matters follows: "Authentication is not required to exploit this vulnerability."
So the code execution is the feature. The defect is that nothing stands in front of it. The advisory carries a CVSS score of 9.8 with a network vector, no privileges and no user interaction required, and credits Peter Girnus, William Gamazo Sanchez and Alfredo Oliveira of Trend Research. It was reported to the vendor in July 2025 and published in January 2026.
One honest caution about the CVE number. The current press wave attributes the exploitation to CVE-2026-0768, the ZDI-disclosed validate-endpoint flaw. VulnCheck’s own writeup ties its larger exploitation counts to CVE-2026-0769, CVE-2025-3248 and CVE-2026-5027 instead. Those numbers are one digit apart and describe near-identical bugs. We could not resolve which one the 360 figure belongs to, and neither, on the published evidence, can anyone else. If you are tracking this by CVE identifier alone, track all of them.
The same bug keeps shipping
This is the part the coverage tends to skip, and it changes what you should do about it.
Censys counts eighteen Langflow vulnerabilities since 2024, fourteen rated high severity and four actively exploited. The first to matter was CVE-2025-3248, also CVSS 9.8, disclosed in May 2025, which OffSec described as "unsafe use of Python’s built-in exec() function to evaluate user-supplied input without sanitization." CISA added it to the Known Exploited Vulnerabilities catalog within weeks.
Since then the pattern has repeated through a validate endpoint, a public flow build endpoint, a shareable playground and a Python REPL component sandbox escape. Different entry points, one bug: a route that executes submitted code, reachable without authentication.
That is not a run of bad luck. It is a product whose core value proposition is executing arbitrary user code, shipping new surfaces that execute arbitrary user code faster than it can put authorization in front of them. Treating each disclosure as an isolated patch event means you will do this again next quarter.
What the requests actually go looking for
Here is where the story stops being about Langflow.
According to BleepingComputer’s account of the observed traffic, the exploitation attempts query environment variables matching LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS* and AWS_SECRET*, read Langflow’s own secret key file, then check for SSH access and look at the size of the shell history. SecurityWeek and SecurityAffairs describe the same sequence independently.
Read that as a list of priorities. The first four items are credentials for services billed by consumption. The security vendor SocRadar makes the underlying point plainly, observing that Langflow "runs user-defined AI workflows and often has credentials for external data and model services."
One thing to be precise about, because the headlines are not. What is documented is systematic probing for these values. We found no report of a confirmed exfiltrated key, a victim disclosure, or stolen credentials appearing for sale. "Attackers are reading the environment for model provider keys" is established. "Attackers have stolen your OpenAI key" is an inference. The distinction matters if you are writing an incident report, and it does not change what you should do.
Worth noting: the observed requests read a secret key file under /root, which tells you something about the privilege level of the instances being hit. The current official Langflow container image explicitly drops to an unprivileged user, so the blanket claim that Langflow "runs as root" does not hold for every deployment. It evidently held for enough of them.
The asset is the key, not the box
A compromised web server gives an attacker compute, a foothold and whatever is on disk. That has a market value, and it is not especially high.
A compromised agent builder gives an attacker a credential for a metered external service that bills your employer, plus a cloud access key, plus whatever data sources the workflows were wired into. The model provider key has properties that make it unusually attractive. It converts directly into compute the attacker does not pay for. It rarely has a spending cap set. Its usage is often reviewed monthly rather than continuously. And revoking it breaks whatever production workflow depended on it, which is the friction that delays revocation.
That is a different risk shape from the one most teams have modeled. "What could someone do if they got onto this box" produces a reassuring answer for a small internal tool. "What is in this box’s environment, and what does it cost per million tokens" produces a very different one.
We made a version of this argument about local AI agent security and again about agent runtime security, where the exploitable surface has moved into the software around the model rather than the model itself. Langflow is the same observation with a price tag attached.
Two precedents that already ran this exact play
If this looks novel, it is not, and the precedents are documented well enough to plan against.
ShadowRay. Oligo Security reported in March 2024 that attackers were exploiting CVE-2023-48022 in the Ray AI framework, an authorization gap on a dashboard whose job is to run submitted code. Oligo documented thousands of exposed Ray servers and listed the stolen material explicitly: cloud credentials for AWS, GCP, Azure and Lambda Labs, API tokens for OpenAI, Hugging Face, Stripe and Slack, SSH keys and Kubernetes tokens. The campaign had been running since at least September 2023 before anyone published on it.
Flowise. In April 2026, a CVSS 10.0 flaw in the Flowise agent builder came under active exploitation. VulnCheck’s Caitlin Condon framed the exposure in the same terms, noting that "the internet-facing attack surface area of 12,000+ exposed instances makes the active scanning and exploitation attempts we’re seeing more serious."
Three products, three years, one pattern. Ray, Flowise and Langflow all execute submitted code as a core function, all ship dashboards, and all sit next to the keys.
Why these end up reachable in the first place
The comfortable explanation is that someone misconfigured a firewall. That is not what the evidence says.
VulnCheck notes that Langflow’s first deployment model "is designed to be deployed as an internet accessible service, allowing public access to your project’s MCP server." Shareable playgrounds and publicly reachable Model Context Protocol endpoints are features, not accidents. Censys measured a 169% increase in internet-exposed Langflow instances over nine months, counting roughly 7,000 during the June 2026 wave, and its assessment is blunt: multiple unauthenticated remote code execution vulnerabilities make any internet-exposed instance a critical finding.
So the mitigation is not only "patch." It is deciding whether the sharing feature that made the tool pleasant is worth the exposure it creates.
What to do if you run one
Upgrade first. Reporting points to release 1.11.6 as the fix, though we could not find a Langflow advisory that names a version against this CVE, so check your installed version against the current release rather than against a number in a news article.
Then do the part that survives the next disclosure.
Put authentication in front of it: a VPN, an authentication proxy or an IP allowlist. Not the application’s own login, which is the thing that has failed four times.
Stop giving it long-lived credentials. Every provider key in that environment should be dedicated to this workload, scoped to the minimum and short-lived. If a key in there can also reach production data, that is the finding, not the CVE.
Set spending limits on model provider keys. This is the one control that turns a credential theft into a bounded loss, and almost nobody has it configured.
Rotate anything that was in the environment. SocRadar advises rotating API keys, database credentials and service tokens where compromise cannot be ruled out, plus Langflow’s own secret key. Given that the documented behavior is reading the environment, assume everything in it is disclosed.
And change how the thing is classified. An agent builder holding provider keys and cloud credentials belongs in the same inventory as your secrets manager, with the same review cadence, the same credential hygiene and the same exposure rules. Most organizations have it filed as a developer convenience.
Frequently Asked Questions
What is the Langflow vulnerability under exploitation?
An unauthenticated remote code execution flaw in Langflow’s custom component validation endpoint, disclosed by Trend Micro’s Zero Day Initiative as ZDI-26-034 and tracked as CVE-2026-0768, rated CVSS 9.8. The validate endpoint executes submitted Python by design, and the defect is that it does not require authentication first.
Which CVE is actually being exploited?
This is genuinely unclear. Press coverage attributes the current wave to CVE-2026-0768, while VulnCheck’s own writeup ties its exploitation counts to CVE-2026-0769, CVE-2025-3248 and CVE-2026-5027. The identifiers are one digit apart and describe near-identical unauthenticated code execution bugs. Track all of them rather than one.
What version fixes it?
Reporting points to 1.11.6, which is a genuine Langflow release. We could not find a Langflow security advisory that names that version against this specific CVE, so treat the number as unconfirmed and upgrade to the current release instead of to a version cited in a news article.
What are attackers taking?
The observed requests probe environment variables matching LANGFLOW_SUPERUSER, OPENAI_API, AWS_ACCESS and AWS_SECRET, read Langflow’s secret key file, and check SSH access and shell history. Systematic probing for those values is documented. A confirmed exfiltration of a live provider key has not been published, so treat theft as a working assumption rather than an established fact.
Does Langflow run as root?
Not universally. The observed exploitation reads a file under /root, which indicates the instances being hit were running privileged. The current official Langflow container image creates and switches to an unprivileged user, so the flat claim that Langflow runs as root is not accurate for every deployment.
Is this in the CISA KEV catalog?
CVE-2026-0768 was not listed when we checked. Five other Langflow CVEs are in the catalog, several of which carried remediation deadlines, so a listing would not be surprising. Do not use its absence as a reason to defer.
How many Langflow instances are exposed?
Censys counted roughly 7,000 internet-exposed instances during the June 2026 exploitation wave, most in North America, and measured a 169% increase in exposure over nine months. Its position is that any internet-exposed instance is a critical finding given the history of unauthenticated code execution in the product.
Is this specific to Langflow?
No. Oligo Security documented the same pattern against the Ray framework in 2024, where attackers took cloud credentials and API tokens for OpenAI, Hugging Face, Stripe and Slack from exposed dashboards. Flowise came under exploitation of a CVSS 10.0 flaw in April 2026 with over 12,000 exposed instances. The common factor is a product that executes submitted code and sits next to credentials.
Why does the model API key matter more than the server?
Because it converts directly into compute billed to you, usually has no spending cap, is typically reviewed monthly rather than continuously, and cannot be revoked without breaking whatever production workflow depended on it. A compromised server gives an attacker a machine. A compromised provider key gives them a budget.
What is the single most useful control?
A spending limit on every model provider key, because it is the one measure that turns an undetected credential theft into a bounded loss. After that, an authentication layer in front of the application rather than inside it, since the application’s own authentication is what has failed repeatedly.
Compliance note. The vulnerability details, CVSS score and disclosure credits come from Trend Micro’s Zero Day Initiative advisory. Exploitation counts and source geography are VulnCheck’s, reported through BleepingComputer, SecurityWeek, Dark Reading and SecurityAffairs; we could not resolve which CVE identifier those counts belong to and have said so. Exposure figures are Censys measurements. The ShadowRay details are Oligo Security’s own report and the Flowise figure is VulnCheck’s, both vendor research about incidents they investigated. No confirmed exfiltration of a live credential has been published by any party, and this piece does not claim one.
