LiteLLM Was Backdoored via Its Security Scanner. Langflow Hit CISA's Exploit Catalog. Same Week.

#security #supplychain #cve #aiinfrastructure

Two tools that appear in most AI development stacks had critical security incidents within 48 hours of each other this week.

On March 24, LiteLLM — the open-source LLM proxy and router used across thousands of enterprise deployments — distributed malicious packages containing a credential-stealing backdoor. The attack window was approximately 5.5 hours.

On March 25, CISA added Langflow to its Known Exploited Vulnerabilities catalog. Langflow is the visual framework for building AI workflows, with 145,000 GitHub stars. CVE-2026-33017 had already been exploited in the wild within 20 hours of the advisory's publication.

Neither incident was subtle. Both were preventable with steps that are not particularly difficult. Together they mark a visible shift: AI development tooling is now a primary attack target, not collateral damage.

The LiteLLM Attack Chain

LiteLLM's compromise traced back to Trivy — a popular open-source container security scanner. Trivy had been compromised via a supply chain attack, and LiteLLM's CI/CD pipeline used Trivy as a dependency.

The result: when LiteLLM's automated build ran, the compromised Trivy component injected malicious code into the resulting packages. Versions v1.82.7 and v1.82.8 were pushed to PyPI through what appeared to be a legitimate maintainer account, but they contained a credential harvester that LiteLLM's team had not written.

According to LiteLLM's post-incident report, the payload was designed to collect:

Environment variables
SSH keys
Cloud provider credentials (AWS, GCP, Azure)
Kubernetes tokens
Database passwords

Stolen data was encrypted and exfiltrated to models.litellm[.]cloud — a domain that looks plausible at a glance. The packages were live on PyPI from 10:39 UTC to 16:00 UTC on March 24. LiteLLM has engaged Google Mandiant for forensic analysis and paused new releases pending a full supply chain review.

Who was at risk: anyone who installed LiteLLM without a pinned version during that window. Users running the official Docker image with pinned dependencies were not affected.

This is the recursive supply chain attack in its clearest form. A security tool used to protect an AI tool became the vector that compromised it. The irony is not subtle. The lesson is: the thing auditing your dependencies can also be the thing that poisons them.

LiteLLM sits in the call path between your application and the LLMs. It processes every prompt, every response, and has access to every API key you've configured. The malicious package didn't need to be clever to reach valuable data. It was already there.

The Langflow RCE

CVE-2026-33017 is a code injection vulnerability in Langflow carrying a CVSS score of 9.3. The vulnerable endpoint is:

POST /api/v1/build_public_tmp/{flow_id}/flow

This endpoint is designed to let unauthenticated users build public flows. The vulnerability arises because it accepts attacker-supplied flow data containing arbitrary Python code in node definitions — and that code executes server-side with no sandboxing.

One crafted HTTP request. Arbitrary Python execution on the host. No authentication required.

Researchers at Endor Labs documented that exploitation started approximately 20 hours after the advisory was published on March 19. No public proof-of-concept existed at the time. Attackers reverse-engineered the exploit directly from the advisory text.

Sysdig's incident timeline shows how fast weaponisation moved:

Hour 0 — advisory published
Hour 20 — automated scanning begins
Hour 21 — Python-based exploitation observed in the wild
Hour 24 — data harvesting activity confirmed

CISA added CVE-2026-33017 to its Known Exploited Vulnerabilities catalog on March 25. Federal agencies running Langflow have until April 8 to patch to version 1.9.0+ or cease using the product.

All versions 1.8.1 and earlier are affected.

What Both Incidents Share

The obvious answer is "supply chain" — but that framing is too broad to be useful here.

Look at the specifics.

LiteLLM sits between your application and the LLMs. It has elevated access because it needs it. The payload targeted exactly the credentials that would give an attacker the most lateral movement: cloud provider keys, database passwords, Kubernetes tokens. Whoever built the attack understood what LiteLLM deployments look like.

Langflow builds AI workflows where node definitions can contain executable code. The vulnerability wasn't in an obscure edge case. It was in the mechanism that makes the platform functional: flow definitions contain code, and the platform executes that code. The public-facing endpoint inherited all of that execution capability without any authentication guard.

These aren't bugs found in peripheral features. They're consequences of what these tools are built to do.

Tools that sit in the execution path of AI workflows — proxies, orchestrators, visual builders — accumulate trust and access because they need it to function. That trust is exactly what attackers are targeting.

The Advisory-to-Exploit Pipeline

The 20-hour exploitation window for Langflow deserves closer attention.

The standard assumption in enterprise security is that you have somewhere between 72 hours and a few weeks between a public CVE and active exploitation. That assumption is based on a world where attackers need to understand the vulnerability, write the exploit, test it, and deploy it.

CVE-2026-33017 invalidated all of that. Attackers read the advisory, extracted the endpoint name and the attack vector description, and had working exploits running before most organisations had finished their morning meetings.

Modern CVE advisories are detailed. They have to be — developers need to understand what's affected to make patching decisions. But a well-written advisory for a code injection vulnerability is also an exploit blueprint. The technical description is the proof-of-concept.

Security teams should treat AI workflow and AI infrastructure CVEs as having a near-zero exploitation delay, not a standard 72-hour window.

What To Do

For Langflow:

Upgrade to version 1.9.0 immediately
If you cannot patch immediately, restrict or disable the POST /api/v1/build_public_tmp endpoint
Do not expose Langflow instances directly to the internet
Rotate any credentials the host had access to

For LiteLLM:

Pin your LiteLLM version in all production deployments
Check whether your environment installed v1.82.7 or v1.82.8 during the March 24 10:39–16:00 UTC window
If it did: rotate everything that LiteLLM had access to — AWS keys, GCP service accounts, database passwords, API keys
Review your PyPI dependency resolution strategy for internal deployments

For AI infrastructure generally:

Your LLM proxy, workflow builder, and agent orchestration layer all have elevated access. Treat them as production services with meaningful blast radii, not developer tools.
Audit what credentials are available in the environments where these tools run.
Pin dependencies. All of them. Especially security tooling used in CI/CD pipelines.
If your AI infrastructure makes outbound network calls, log them. An unexpected call to an unrecognised domain is the earliest signal you'll get.

Neither of these incidents required a sophisticated attacker. LiteLLM needed someone willing to spend time on a supply chain attack that would have wide downstream reach. Langflow needed someone who could read a CVE advisory and write a Python HTTP request.

The tools we use to build AI systems are now valuable targets in their own right. That's new, and it changes the threat model for anyone operating AI infrastructure.

Sources: LiteLLM security incident report (March 24, 2026) · BleepingComputer: Langflow CVE-2026-33017 · Sysdig: 20-hour exploitation timeline · The Hacker News: Endor Labs research

Originally published on mistaike.ai