Twelve Exploited CVEs in One Year: Why Attackers Keep Coming Back to Langflow

Twelve distinct Langflow vulnerabilities have been exploited in the wild during 2026. In all prior years combined, there was one. Cumulative successful exploitation attempts across that set exceed 15,000.

That’s not a run of bad luck. It’s a signal about what AI development infrastructure has become worth attacking.

The current one

CVE-2026-0768 is a CVSS 9.8 unauthenticated remote code execution flaw in Langflow’s custom component editor — specifically the code validator. Published as a zero-day advisory by ZDI on January 9, 2026, it affects Langflow 1.4.2 and earlier.

The mechanism is about as simple as RCE gets: the validate endpoint takes a user-supplied code parameter and passes it to Python’s exec() without sanitization. No authentication required, and execution happens with root privileges.

VulnCheck detected exploitation attempts on its UK honeypots hours before public disclosure. At least 50 attempts over a weekend escalated to 360 observed attacks, with traffic originating primarily from Russia. Separate analysis put the targeted population at roughly 7,000 internet-exposed servers.

What attackers actually take

This is the part that makes the story about more than one CVE. Per VulnCheck’s Caitlin Condon, after gaining root execution the attacker performs reconnaissance and queries environment variables, going after:

• OPENAI_API_KEY and Anthropic tokens
• AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY, plus GCP and Azure credentials
• Langflow superuser authentication keys
• Database connection strings
• /root/.cache/langflow/secret_key
• .ssh access and .bash_history, for lateral movement

Nobody is attacking Langflow because they want your flow diagrams. They’re attacking it because a server that runs your AI workflows is also a server that holds every credential those workflows need — LLM provider keys, cloud credentials, database access — usually as static values in environment variables.

That’s an architectural property, not a Langflow defect. Any self-hosted platform that executes user-defined workflows and stores long-lived provider keys has the same shape. Langflow is getting hit because it’s popular and internet-exposed, not because it’s uniquely careless.

The pattern across 2026

The repeat exploitation is worth walking through, because the through-line is consistent:

• CVE-2026-33017 (March) — unauthenticated RCE in the public flow build endpoint, weaponized within roughly 20 hours of disclosure, used to harvest OpenAI, Anthropic and AWS credentials before pivoting to Monero cryptomining. Added to CISA KEV on March 25.
• CVE-2026-5027 (CVSS 8.8) — path-traversal arbitrary file write via the files endpoint, escalatable to RCE, with active exploitation observed.
• CVE-2026-55255 — unauthorized access to AI workflows, data theft, second-stage malware.
• CVE-2026-0770 — root-level command execution for credential extraction and malware deployment.
• CVE-2026-9198 — flagged by CISA after multiple public PoCs surfaced.

Two structural problems show up repeatedly in this list.

First: incomplete patching. CVE-2025-3248, disclosed April 2025, was a different RCE in the same validate endpoint, fixed in Langflow 1.3.0. CVE-2026-0768 is a subsequent injection in the same functional area. JFrog Security Research separately found that versions reported as patched for related CVEs remained exploitable after fixes shipped. A version number saying “fixed” has not been a reliable signal here.

Second: the exploitation window is shorter than the patch window. Twenty hours from disclosure to weaponization, in the March case. Exploitation attempts before public disclosure, in the current one. If your response plan assumes you get days, the observed data disagrees.

What to do if you run Langflow

Immediate, in rough priority order:

1. Find internet-exposed instances. This is the single biggest risk factor — the exploited population is exposed servers, and many are exposed by accident rather than intent.
2. Set LANGFLOW_AUTO_LOGIN to false, and enforce authentication at the network edge rather than relying on the application alone.
3. Restrict network access to Langflow instances. There is rarely a good reason for one to be reachable from the open internet.
4. Rotate exposed credentials — OpenAI, Anthropic, AWS, GCP, Azure, database strings. If you were exposed, assume harvested. Rotation after the fact is the only remedy; there’s no unringing this bell.
5. Review environment variables and local secret files for signs of unauthorized access, and check .bash_history for lateral movement attempts.

The architectural fix, and its cost

Patching faster is necessary but insufficient given the twelve-CVE track record and the incomplete-patch history. The structural change that actually reduces blast radius:

Stop embedding static API keys in flows. Move to brokered, short-lived credentials through something like Vault or a cloud KMS. A stolen 15-minute token is an incident. A stolen long-lived OPENAI_API_KEY is a bill and a breach.

The more radical version of this argument — and it’s a legitimate one — is that a server which both executes your flows and holds your keys is inherently a high-value target, and the safest architecture is one where no hosted endpoint executes anything. That trade is real: you give up one-click cloud runs in exchange for having nothing to breach. Whether that’s worth it depends entirely on how much the convenience is actually buying your team.

What isn’t defensible anymore is treating AI tooling as outside your vulnerability management program. Twelve exploited CVEs in twelve months puts Langflow-class infrastructure in the same tier as any internet-facing application server, and it should inherit the same patching, exposure monitoring, and credential hygiene.

Official reference: ZDI advisory for CVE-2026-0768, VulnCheck’s exploitation telemetry, Cloud Security Alliance research notes on the Langflow exploitation pattern, and reporting from BleepingComputer and GBHackers. Exploitation counts are point-in-time observations from honeypot data and will have moved since publication.