Langflow CVE-2026-0768: the 12th Langflow flaw exploited in the wild this year

CVE-2026-0768 is an unauthenticated remote code execution flaw in Langflow, the open-source visual framework for assembling large language model pipelines and agents, and attackers were using it in the wild by the end of August 2026. The flaw sits in the code validator behind Langflow's custom-component editor: the validate endpoint accepts a code parameter and runs the Python it contains, with no authentication and, in the Zero Day Initiative's wording, "in the context of root." VulnCheck's Canary honeypot network recorded more than 50 exploitation attempts within hours of the first detections on 30 August 2026, and more than 360 by Monday 1 September, all against sensors in the United Kingdom; VulnCheck's Caitlin Condon said the source traffic primarily originated in Russia. The requests were not ransomware. They read environment variables holding Langflow superuser credentials, OpenAI API keys and AWS access and secret keys, then went looking at /root/.cache/langflow/secret_key, .ssh and .bash_history. The archive's full entry for this incident, including its severity, confidence and harm classifications, sits in the Orca AI Incident Archive, alongside the other credential-theft and AI-infrastructure records that surround it.

Security Affairs published its account on 2 September 2026; SecurityWeek's Ionut Arghire reported the exploitation the day before, BleepingComputer's Bill Toulas covered it that week, and the Cloud Security Alliance's AI Safety Initiative followed on 4 September with a research note that restates the mechanism and adds recommendations. None of the accounts reviewed for this article named a compromised organisation. Everything traces back to VulnCheck's own sensors and to the advisory the Zero Day Initiative published in January.

An editor that executes what it is asked to validate

Langflow's selling point is that you assemble an AI application by dragging components onto a canvas. Custom components are Python: the editor lets a user paste code and press validate, and the server checks it. According to ZDI advisory ZDI-26-034, that check runs the code. The advisory's root-cause sentence is one line — "the lack of proper validation of a user-supplied string before using it to execute Python code" — and the outcome is that a single unauthenticated HTTP request executes arbitrary Python on the host.

Three properties turn that into an incident rather than a bug report. The CVSS vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, scored 9.8: reachable over the network, low complexity, no privileges, no user interaction, and total loss of confidentiality, integrity and availability. The execution context is root, which is why the attacker commands that Condon and the Cloud Security Alliance both describe head for /root/.cache/langflow/secret_key — the file Langflow uses to encrypt stored credentials and session data. And the endpoint asks for no credentials at all, so exposure is a function of reachability alone.

The disclosure history matters to how this played out. ZDI's timeline records the report reaching Langflow's GitHub account on 18 July 2025, a request for updates on 11 September 2025, a request for the fix on 10 October 2025, and notice of intent to publish as a zero-day on 10 December 2025. ZDI released the advisory on 9 January 2026. The researchers credited are Peter Girnus, William Gamazo Sanchez and Alfredo Oliveira of Trend Research. GitHub's advisory database carries the same text as GHSA-x5pr-rvjj-j6qm, published 23 January 2026, classified CWE-94, and lists no affected version range at all. ZDI's stated mitigation is not a patch: it is to "restrict interaction with the product."

Public reporting places the affected range at Langflow releases up to and including 1.4.2, the version the Metasploit module added later was built and tested against. That is where the certainty ends, and the section on fixes below sets out why.

What 360 detections do and do not establish

VulnCheck's Canaries are internet-facing sensors built to look like the thing an attacker is scanning for. The firm saw first-time exploitation of CVE-2026-0768 on 29–30 August 2026: more than 50 detections in a few hours on the Sunday, rising past 360 by the Monday. Condon, VulnCheck's vice president of threat research, described the activity on LinkedIn as "a mix of reconnaissance and credential harvesting," adding that source traffic primarily originated in Russia and had "thus far exclusively hit Canaries in the U.K."

The command sequence the sensors captured is specific enough to be a playbook. Attackers queried the environment for LANGFLOW_SUPERUSER, for variables matching OPENAI_API, and for AWS_ACCESS and AWS_SECRET keys — the three credential families a Langflow host is most likely to hold. They read the cached secret key at /root/.cache/langflow/secret_key. They checked for .ssh access and inspected the size of .bash_history, both of which indicate whether an operator can move laterally rather than merely read secrets. A community write-up of the chain, cited by the Cloud Security Alliance, adds that the same activity searched source trees and .env files for embedded secrets, exfiltrated what it found, and checked whether a host had already been backdoored by a previous operator before adding its own persistence.

What that establishes is that the exploit works, that it was used against internet-facing Langflow instances, and that the objective was credentials rather than disruption. What it does not establish is a victim. Canaries are decoys; a detection is a request, not a confirmed theft. The archive classifies this record as real harm, and the harm documented in the public sources is the confirmed execution of credential-harvesting code against exposed systems — not a named organisation whose keys were spent.

One detail cuts against the usual story about disclosure. According to VulnCheck, no public proof-of-concept for CVE-2026-0768 existed when exploitation began. The advisory had been public for nearly eight months and described the flaw precisely enough for someone to build an exploit from the text. The firm's read, as reported by The Hacker News, is that this was independent derivation rather than reuse of leaked code.

Twelve flaws, fifteen thousand attempts — and where those numbers bend

The statistic that gives this incident its weight comes from VulnCheck, and it is worth quoting in the firm's own words rather than in paraphrase. "Before 2026, evidence showed only one Langflow vulnerability known to be exploited in the wild," it said. "In 2026, things have changed fast." SecurityWeek reports VulnCheck as tracking "11 additional vulnerabilities targeted and reported as exploited in the wild" during 2026.

Add those and you get twelve exploited Langflow vulnerabilities, one of which predates the year. That is not the same as twelve in 2026, and the sources slide between the two framings. Forkast's headline calls CVE-2026-0768 "Langflow's 12th Exploited CVE of 2026," while the same article's body describes the dozen as "11 new vulnerabilities and one identified prior to the start of the year." The record's title follows the headline. Read strictly, 2026 accounts for eleven of the twelve, with the twelfth — the one known before this year — making up the balance.

The 15,000 figure has a comparable edge. SecurityWeek, The Hacker News and Forkast all attribute "over 15,000 successful attacks" to three named vulnerabilities: CVE-2026-0769, CVE-2025-3248 and CVE-2026-5027. That is a large number, but it is a count across three CVEs, not across Langflow's whole 2026 portfolio. Phrasing it as exploitation attempts against the portfolio — as the archive's summary does — is broader than what VulnCheck published.

The individual entries behind the pattern are documented. CVE-2025-3248 was a code-injection flaw in the same /api/v1/validate/code endpoint, patched in Langflow 1.3.0 by replacing execution with compile-only validation, according to GitHub advisory GHSA-rvqx-wpfh-mfx7 as cited by the Cloud Security Alliance — which means CVE-2026-0768 is the same class of bug in the same code path, roughly four months after that fix shipped. CVE-2026-33017, an unauthenticated RCE in the public flow build endpoint, was weaponised within about 20 hours of its March 2026 disclosure and used to take OpenAI, Anthropic and AWS credentials before pivoting to Monero cryptomining, in the Cloud Security Alliance's account. The same alliance's note of 12 June 2026 covers CVE-2026-5027, a path-traversal flaw in the file-upload endpoint that researchers linked to the Iranian state-sponsored group MuddyWater, and its 4 September note records CVE-2026-55255, an authorisation bypass letting an authenticated user run another user's flows, going onto CISA's Known Exploited Vulnerabilities catalog on 7 July 2026. Those four share a shape: an endpoint that either skipped authentication or skipped sanitisation, in a platform whose job is to hold credentials for everything it talks to.

Why an orchestration platform is worth the trouble

A production Langflow instance is configured with provider API keys, cloud credentials, database connection strings and integration secrets, because the flows it runs need them at call time. Compromise of the host therefore yields working access to every service whose credentials the instance stores. Stolen OpenAI or Anthropic keys let an attacker bill inference to the victim or impersonate the organisation downstream; stolen AWS keys open infrastructure well beyond the Langflow container. That leverage, rather than any AI-specific capability, is what the observed commands were going after.

The Cloud Security Alliance's judgement is that recurrence across four different Langflow subsystems in a single year — code validator, public flow build endpoint, file upload, workflow execution — points to a systemic gap in security engineering rather than a run of unrelated defects. That is the alliance's assessment, offered in a research note, not a finding by an independent auditor, and Langflow has not responded to it publicly in the material reviewed here.

What was fixed, and what is still ambiguous

This is the weakest part of the public record, and it is worth being precise about why. ZDI's advisory names no patched version. Snyk's database entry for the CVE lists affected versions as everything before 1.10.1 and recommends upgrading to 1.10.1 or higher. Public reporting, including SecurityWeek and Security Affairs, describes the affected range as releases through 1.4.2 but identifies no fixed release. The Cloud Security Alliance noted on 4 September that Langflow's maintainers had not published a dedicated security advisory naming this CVE, and that trackers disagreed about which release actually remediated it — an ambiguity the alliance says echoes an earlier Langflow case where a version reported as fixed remained exploitable.

Langflow did ship fixes in the right area, on the right day. Version 1.11.6 was published on 1 September 2026, the Monday the honeypot count passed 360, and its release notes describe a backport of security fixes including "close component code scan gaps" and "resolve annotations without execution" (pull request 14876). Version 1.12.0 followed that evening. Further hardening of the same code path continued afterwards: a later pull request titled "stop validate_code from executing imports" indicates the validate endpoint was still being tightened weeks after the first exploitation. None of that constitutes a vendor statement that CVE-2026-0768 is fixed in a named release, and none was found in the record's cited sources.

What changed on the attacker side is clearer. A Metasploit exploit module for the flaw was opened as a pull request on 2 September 2026 — the same day Security Affairs published — and merged on 8 October 2026, tested against Langflow 1.4.2. Whatever the state of the original derivation, exploiting this flaw stopped requiring original work six weeks after it started being exploited.

The Cloud Security Alliance's recommended response is a patch-and-rotate sequence rather than a patch alone: verify the running version and move to the current stable release; treat any internet-exposed instance on an affected version as compromised until proven otherwise, because the observed activity is silent harvesting rather than visible disruption; and rotate every secret the instance could reach — the Langflow superuser password, provider API keys, AWS access and secret keys, and the Langflow secret key itself, re-encrypting stored credentials rather than merely replacing the file. It also recommends auditing access logs for requests to the validate endpoint, checking authorized_keys for unfamiliar SSH keys, and looking for evidence that a previous operator had already backdoored the host. Where the platform must stay reachable, it suggests gating or disabling the validate endpoint and moving away from long-lived high-privilege keys stored directly in the platform.

Established, reported, and not established

Established: that CVE-2026-0768 is an unauthenticated RCE in Langflow's validate endpoint that executes Python as root, documented in ZDI-26-034 and mirrored as GHSA-x5pr-rvjj-j6qm; that exploitation began on 29–30 August 2026; that VulnCheck recorded more than 50 detections in hours and more than 360 by 1 September, against UK sensors, with traffic primarily from Russia; and that the observed requests targeted Langflow superuser, OpenAI and AWS credentials plus the cached secret key, .ssh and .bash_history. These come from the advisory itself and from VulnCheck's telemetry as reported independently by SecurityWeek, Security Affairs and The Hacker News.

Reported, not independently verified: every detection count. The 50, the 360 and the 15,000 are VulnCheck's own figures, published by the firm and repeated by outlets that credit it; no second honeypot network has published a corroborating count. The attribution to Russian infrastructure is likewise VulnCheck's reading of source traffic, not an assessment any government or CERT has endorsed in the material reviewed.

Not established: that any named organisation lost credentials. No victim has been identified in the record's sources. Nor is there a confirmed patched version: ZDI names none, Snyk says 1.10.1, reporting says affected through 1.4.2, and the 1.11.6 release notes describe security fixes without tying them to this CVE. Nor is the "twelfth flaw of 2026" count internally consistent across its own sources, as set out above.

The part that should worry people who patch on a schedule

The eight-month gap is the finding. CVE-2026-0768 was published as a zero-day on 9 January 2026, with a technical description detailed enough to rebuild from, and nothing happened against VulnCheck's sensors until the last weekend of August. Then several hundred attempts arrived in three days, from operators who, on the firm's account, had no public exploit to copy. Whatever kept those instances unpatched through eight months of a public critical advisory is the same thing that made the flaw worth exploiting when someone finally wrote the code.

It also closes a loop the earlier Langflow CVEs opened. CVE-2025-3248 was fixed by removing execution from the same validate path; CVE-2026-0768 executes on that path anyway. A fix that removes a behaviour without removing the design decision that produced it buys time, and in this case it bought about four months.