Exposed AI Gateways: How LiteLLM and Langflow Flaws Are Being Found and Exploited

Open-source LLM proxies and agent-builder tools are getting patched, scanned, and exploited on the same news cycle. Here's what's actually verified about the LiteLLM and Langflow flaws driving that, and how to find your own exposure before someone else does.

The pattern nobody planned for

Most teams didn't choose to stand up an "AI gateway." Someone needed a quick way to route a prototype through three different model providers without juggling API keys in every service, so they pulled LiteLLM or Langflow off GitHub, ran it in a container, and moved on. Eighteen months later that container is still running, it's reachable from the internet because nobody put it behind the VPN, and it's holding OpenAI, Anthropic, and internal database credentials in one place.

That's not a hypothetical. It's the shape of nearly every AI gateway incident from the past year, and it's why this class of software has become a favorite target for opportunistic scanning.

What's actually verified: four CVEs, two products

Two of the most-discussed AI gateway flaws in 2025–2026 sit in Langflow, an open-source visual builder for AI agent workflows. Two more sit in LiteLLM, an open-source proxy that fronts multiple LLM providers behind one API. All four have been confirmed by their vendors and added to CISA's Known Exploited Vulnerabilities (KEV) catalog, which is a meaningfully higher bar than "a PoC exists on GitHub."

Langflow: when "public by design" swallows the whole server

CVE-2025-3248 is the older and better-documented of the two Langflow bugs. Versions before 1.3.0 exposed a /api/v1/validate/code endpoint that was supposed to check whether a submitted Python function was well-formed. Instead, it parsed the code into an abstract syntax tree and executed pieces of it directly, with no authentication and no sandboxing. An attacker could hide a payload inside a decorator or an argument default and get it to run on the server with a single unauthenticated HTTP request. CISA added it to the KEV catalog on May 5, 2025, and multiple trackers note it has been tied to ransomware activity and to the Flodrix botnet [3].

CVE-2026-33017 is a different bug in a related idea. The /api/v1/build_public_tmp/{flow_id}/flow endpoint exists so that a "public" flow can be shared and executed without a login — that's intentional. The problem is that it accepts attacker-supplied flow data, including Python code embedded in node definitions, instead of only using what's stored in the database. Sysdig's threat research team disclosed exactly how fast that gap got weaponized: their honeypot fleet recorded the first real exploitation attempt about 20 hours after the advisory went public, and no public proof-of-concept existed yet when that happened. Attackers built a working exploit straight from the advisory text [4].

What Sysdig watched unfold is worth sitting with. Automated scanners running nuclei templates hit their honeypots first, identifiable by things as mundane as rotating a User-Agent string through a list that included "Knoppix" and "Fedora" — nothing a real browser sends. Behind the scanners came operators with custom Python scripts who moved methodically: list the filesystem, read /etc/passwd, dump environment variables, then pull down a second-stage payload from pre-staged infrastructure. Two of the IPs Sysdig tracked exfiltrated data to the same command-and-control server, which suggests one operator working through multiple hosts rather than four unrelated attackers [4].

LiteLLM: a proxy is a credential store wearing an API

LiteLLM's two headline 2026 bugs live in different parts of the proxy but share a theme: the software's job is to hold every connected provider's API keys, and both flaws let someone reach that store.

CVE-2026-42208 is a SQL injection triggered when a malformed API key fails validation on any LLM endpoint, including the ordinary /chat/completions route. The error-handling path lets an attacker's payload run against the database instead of just rejecting the bad key [1][2]. CISA confirmed active exploitation and added it to KEV on May 8, 2026.

CVE-2026-42271 sits in a more specific corner: the Model Context Protocol (MCP) integration. LiteLLM added two "test" endpoints, /mcp-rest/test/connection and /mcp-rest/test/tools/list, meant to let an admin preview an MCP server configuration before saving it. Both accepted a full stdio-transport config — including the literal command to run — and executed it as a subprocess on the proxy host. The catch was authorization, not authentication: any holder of a valid API key, even a low-privilege one, could reach these test endpoints, because they weren't gated behind the admin role the way the real save endpoint was. The GitHub Security Advisory is explicit that the fix in 1.83.7 brought both endpoints "into line with the save endpoint" by requiring the PROXY_ADMIN role [1]. CISA added this one to KEV on June 8, 2026 [2].

Research from the Cloud Security Alliance describes a chain worth understanding separately from either individual CVE: a Host-header validation flaw in Starlette (the ASGI framework underneath LiteLLM's proxy) can bypass LiteLLM's authentication layer entirely, which turns CVE-2026-42271 from "any authenticated user" into "no login required at all." The fix requires upgrading both LiteLLM to 1.83.7 and Starlette to a patched release — patching one without the other leaves the chain intact.

None of this is LiteLLM's only 2026 incident, either. In March 2026, someone compromised a maintainer's PyPI account and published two malicious releases, 1.82.7 and 1.82.8, containing a base64-encoded loader that installed a credential-stealing payload on import. It was caught almost by accident, when engineers testing an unrelated Cursor MCP plugin noticed their machine grinding to a halt from RAM exhaustion and traced it back to LiteLLM as a transitive dependency [5]. It's a separate attack surface from the CVEs above — supply chain versus application vulnerability — but it reinforces the same point: a tool that touches every model credential in your stack is worth an attacker's time on more than one front.

How exposed is "exposed," really

Numbers here need to stay attached to their specific CVE and date, because they move fast. Recorded Future counted roughly 1,050 Langflow instances reachable on Shodan around the time CVE-2025-3248 was being actively scanned in 2025, while noting that not every instance found that way was necessarily running a vulnerable version [6]. By 2026, reporting on a separate Langflow path-traversal flaw, CVE-2026-5027, cited Censys data putting exposed Langflow instances at roughly 7,000, mostly in North America [7]. Those two figures describe different vulnerabilities at different points in time — they're not a before-and-after of the same population — but together they say something simple: Langflow deployments facing the open internet aren't rare, and the count hasn't been shrinking.

Neither Recorded Future nor Censys distinguishes "vulnerable version" from "exposed at all" with certainty, and this article doesn't either. Take exposure counts as an attack-surface signal, not a precise vulnerable-host tally.

Finding your own exposure

The practical starting point isn't a CVE scanner — it's asset inventory, because you can't patch what you don't know is running. runZero's security research team published the query they use to spot LiteLLM instances from HTTP service banners: _asset.protocol:http AND protocol:http AND (html.title:="LiteLLM%" OR last.html.title:="LiteLLM%") [2]. The same logic applies with any exposure-management or attack-surface tool you already run — search for the product's default page title, its default port, and its characteristic API paths, then cross-reference against your list of approved external-facing services.

A short, practical checklist for either product:

• Enumerate every host running LiteLLM or Langflow, including ones spun up by individual teams outside central IT — shadow AI infrastructure is the norm here, not the exception.
• Check the running version against the fixed versions in the vendor advisory, not just against "latest," since some deployments pin old images deliberately.
• Confirm the instance isn't reachable from the open internet unless it genuinely needs to be, and if it does, put it behind an authenticating reverse proxy.
• Rotate provider API keys and database credentials for any instance that was exposed on a vulnerable version, even if you see no direct evidence of compromise — the SQL injection and MCP command-injection paths are both built for silent credential access.
• Pin dependency versions for LiteLLM's PyPI package and verify checksums after the March 2026 supply-chain incident, rather than trusting automatic upgrades to always pull a clean release.

What's still genuinely unclear

A few things are worth flagging as open rather than settled. CVE-2026-33017 was confirmed exploited by Sysdig's own honeypot data but, at the time of their publication, had not yet been added to CISA's KEV catalog — KEV listing and confirmed exploitation aren't the same trigger, and the two can be out of sync for a while [4]. The exposure counts cited above come from two different scanning services measuring two different CVEs at two different points in time, so they shouldn't be read as a trend line for one static population of servers. And while the Starlette Host-header bypass has been described publicly as removing LiteLLM's authentication requirement when chained with CVE-2026-42271, this article isn't citing a specific CVE identifier for that Starlette issue because none of the sources reviewed assigned one directly in the passages checked — treat that detail as a documented chaining risk rather than a numbered vulnerability you can look up on its own.

The takeaway

None of these four CVEs are exotic. A missing auth check, a SQL injection in error handling, an authorization gap on a "just for testing" endpoint, an unsandboxed template renderer — these are ordinary web-application bugs. What makes them worth an entire article is where they live: a piece of infrastructure that, by design, holds the keys to every LLM provider an organization uses, often deployed faster than it was reviewed. Sysdig's honeypots turned up a working exploit within a single day of disclosure, before any public PoC existed. Treat that as the baseline speed you're up against, and start with inventory — you can't defend a gateway you forgot you stood up.

Sources & References

1. GitHub Security Advisory GHSA-v4p8-mg3p-g94g — LiteLLM: Authenticated command execution via MCP stdio test endpoints (CVE-2026-42271)
2. runZero — LiteLLM Proxy vulnerabilities: How to find impacted assets
3. Security Affairs — U.S. CISA adds a Langflow flaw (CVE-2025-3248) to its Known Exploited Vulnerabilities catalog
4. Sysdig Threat Research Team — CVE-2026-33017: How attackers compromised Langflow AI pipelines in 20 hours
5. HeroDevs — The LiteLLM Supply Chain Attack: What Happened, Why It Matters, and What to Do Next
6. Recorded Future — Langflow: CVE-2025-3248: Active Exploitation
7. The Hacker News — Langflow Vulnerability CVE-2026-5027 Exploited for Unauthenticated RCE