VulnCheck’s decoy Langflow hosts logged more than 50 exploitation attempts within hours on August 30, 2026 and 360 by the following day. The CVE record for the flaw names one affected version, no fix, and a single third-party reference — and Langflow’s own published advisory list does not contain it at all.
What happened
On Sunday, August 30, 2026, VulnCheck began seeing attempts against CVE-2026-0768 on its Langflow canaries — intentionally vulnerable instances the firm runs to watch what attackers do. More than 50 landed within hours. By Monday, August 31, the count was over 360.
Caitlin Condon, VulnCheck’s vice president of threat research, described what the requests were reaching for: “Among other things, attacker requests are querying environment variables (LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS*, AWS_SECRET*), reading /root/.cache/langflow/secret_key, and checking .ssh access and .bash_history size.” She characterized the activity as a mix of reconnaissance and credential harvesting, and said the source traffic “primarily originates from Russia and has thus far exclusively hit Canaries in the U.K.”
Read that environment-variable list again. It is not what a botnet operator wants. It is the specific set of secrets a Langflow deployment is likely holding: the platform’s own superuser credential, an OpenAI API key, and AWS access and secret keys. Whoever wrote the payload knew what this software is for.
The flaw itself is old. The Zero Day Initiative published ZDI-26-034 on January 9, 2026 as a 0Day advisory, credited to Peter Girnus, William Gamazo Sanchez and Alfredo Oliveira of Trend Research, under ZDI-CAN-27322. The report had gone to the vendor on July 18, 2025 — nearly six months before publication, and now more than thirteen months ago.
The description on the CVE record is ZDI’s, reproduced verbatim by NVD: “Langflow code Code Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Langflow. Authentication is not required to exploit this vulnerability. The specific flaw exists within the handling of the code parameter provided to the validate endpoint. The issue results from the lack of proper validation of a user-supplied string before using it to execute Python code. An attacker can leverage this vulnerability to execute code in the context of root.”
No authentication. Code execution as root. ZDI scored it CVSS 3.0 9.8 with the vector CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. NVD published the record on January 23, 2026 at 4:16 a.m. UTC.
What the record says, and what it does not
The NVD record for CVE-2026-0768 has not been modified since June 17, 2026. Here is everything it contains about which software is affected: Langflow, version 1.4.2. One version. Every other version carries the default status “unknown.” It lists one reference — the ZDI advisory — and names no fixed version. There is no vendor advisory link, no patch commit, no GitHub Security Advisory.
ZDI’s advisory offers the mitigation it reserves for flaws with no vendor fix: restrict interaction with the affected product. That is the guidance a defender following the primary sources gets today. Not “upgrade to X.” Put a firewall in front of it.
Langflow’s own GitHub Security Advisories database lists ten published advisories, from GHSA-5993-7p27-66g5 in December 2025 through GHSA-9whx-c884-c68q in April 2026 and GHSA-v5ff-9q35-q26f in May 2026. Several are critical unauthenticated remote code execution. None of them is CVE-2026-0768. The project has an advisory process, has used it repeatedly for flaws of the same class, and has not used it here.
The reporting that broke the exploitation news says the fix is Langflow 1.11.6, and that everything up to 1.4.2 is affected. Both statements are probably right and neither is in any primary record we could find. NVD says 1.4.2, singular. No advisory we located names 1.11.6. This publication covered three other Langflow code-execution CVEs on August 28, all of them documented by IBM in a security bulletin under the product name IBM Langflow OSS, with the affected range given as 1.0.0 through 1.11.1 and the fix as 1.11.2. That machinery exists. It was not applied to this CVE.
One more number. EPSS, the Exploit Prediction Scoring System, rates CVE-2026-0768 at 0.02338 — a 2.3 percent probability of exploitation in the next thirty days, which its scale calls low. That figure was current while VulnCheck’s sensors were logging 360 attempts in two days.
The flaw is not in the CISA Known Exploited Vulnerabilities catalog. Its NVD record carries no cisaExploitAdd, no cisaActionDue and no cisaVulnerabilityName. There is no federal deadline attached to it.
Why it matters
Everything an operator would use to triage this flaw says it is quiet. One affected version on the record. No fixed version, so no upgrade appears in a patch queue. No vendor advisory, so no vendor feed carries it. Not in KEV, so no compliance clock. EPSS at 2.3 percent, so a risk-scored backlog sorts it near the bottom. A team doing careful, tool-driven vulnerability management using only authoritative sources would not have this in front of them this week — and it is the one being used against them.
The gap is not that the record is wrong. Nothing on it is false. The gap is that the record was written once, in January, from a third-party disclosure, and nothing has updated it since June. Records maintained by exception decay quietly, and the decay is invisible until someone starts exploiting the thing.
The second point is about what Langflow is. It is a low-code builder for LLM applications, and its deployment model puts it on a network interface so people can use the visual editor. A machine running it is, almost by construction, a machine holding a model-provider API key and cloud credentials, because that is what the flows it builds need. Root code execution on that host is not a foothold on a random web server; it is a foothold on the box where an organization keeps the keys to its AI spending and, frequently, its cloud account. The payload Condon describes goes straight for exactly those three things and nothing else.
This is the AI-infrastructure compromise forecast in the abstract for two years, arriving as something ordinary: an old unpatched web flaw on a tool nobody put in the asset inventory, used to read environment variables. No model exploit, no prompt injection, no agent misbehavior. Just a validate endpoint that runs the string you send it.
Finally, the sourcing. Everything known about the exploitation comes from one firm’s honeypots. VulnCheck has published payload details and counts, which is more than most single-source claims carry, but 360 attempts against canaries in one country is a measure of scanning, not of compromise. Nobody has published a count of Langflow instances that were actually taken. Nobody has published an indicator list. The vendor has said nothing. Treat the exploitation as real and the scale as unmeasured.
What to do
Find the Langflow instances first, because they are usually not in the inventory. They arrive as a data-science convenience, run under a personal account, and get exposed so a colleague can open the editor. Look for listeners on the default port and for hosts with LANGFLOW_ variables in their environment.
Upgrade. Reporting says 1.11.6 closes it; the primary record does not confirm that, so upgrade and then verify rather than assuming. Independent of this CVE, 1.11.2 is the documented fix for the three code-execution flaws IBM disclosed on August 28, so anything below 1.11.6 is behind on several counts.
Until you have upgraded, take ZDI’s advice and restrict reachability — Langflow does not belong on the public internet in any configuration, and the exploitation traffic is arriving unauthenticated from outside.
Then rotate. If an instance was internet-reachable at any point since August 30, 2026, assume the environment was read: rotate the OpenAI or other model-provider API keys on that host, rotate the AWS access and secret keys, rotate LANGFLOW_SUPERUSER, and replace the contents of /root/.cache/langflow/secret_key. Then check your model-provider billing and cloud audit logs for use from unfamiliar addresses since August 30. Credential harvesting shows up as spend before it shows up anywhere else.
Sourcing note
Checked: the NVD record for CVE-2026-0768 for its description, CVSS metrics, affected-version configuration, references, publication and last-modified dates, and the absence of CISA KEV fields; ZDI-26-034 for the disclosure timeline, ZDI-CAN number, credited researchers and mitigation language; the langflow-ai/langflow GitHub Security Advisories index for whether the project published an advisory for this CVE; and an independent CVE aggregator for the EPSS score and the “no vendor fix or workaround currently provided” status. The exploitation details and the Condon quotations come from BleepingComputer’s and The Hacker News’s September 1, 2026 reports of VulnCheck’s findings.
Could not reach: VulnCheck’s own posting of these Langflow observations. The firm’s published Langflow research of August 28, 2026 covers twelve other CVEs and attacker activity from May 12 to June 25, 2026, and does not mention CVE-2026-0768; the August 30 telemetry appears to have been released through Condon’s social posts, which we could not fetch directly. The quotations here are as the two outlets reported them. cisa.gov returns 403 to automated fetching, so KEV status was read from the NVD record, which republishes CISA’s fields.
Unresolved: whether Langflow 1.11.6 in fact fixes CVE-2026-0768, which no primary source we found states. Why neither Langflow nor IBM has published an advisory for a 9.8 unauthenticated root RCE in their product thirteen months after it was reported and nearly eight months after it was published. Whether any instance has actually been compromised, as opposed to probed. And whether NVD will update a record that has named one affected version since January.