TL;DR
- Censys counted publicly detectable AI/LLM tools on distinct IP addresses. That measures visibility. It does not count vulnerable systems, production deployments, or organisations.
- The number that carries weight is CVE-2026-42208: a critical pre-authentication SQL injection in the LiteLLM proxy’s API-key verification path, patched in 1.83.7 and added to CISA’s Known Exploited Vulnerabilities catalogue on 8 May 2026.
- Practical consequence for anyone running an AI gateway: the design that centralises provider keys to simplify management also concentrates what one unauthenticated request can reach. Patch to 1.83.7 or later, get the proxy off the public internet, and rotate keys if an affected deployment was reachable.
- Censys’s own write-up overstates its primary source on the impact. Take the advisory’s wording over the vendor blog’s when you describe the blast radius.
In plain English
An AI gateway (or LLM proxy) sits between your application and the model providers you call. Instead of every service holding its own OpenAI, Anthropic and Google keys, they all call the gateway, and the gateway holds the keys and routes the request. LiteLLM is a widely used open-source example. The appeal is real: one place to manage credentials, set spend limits and switch providers.
A pre-authentication SQL injection is a flaw where an attacker can manipulate the database queries an application runs before proving who they are. If the vulnerable query is the one checking whether your API key is valid, the check meant to keep strangers out becomes the way in.
CISA KEV is the US Cybersecurity and Infrastructure Security Agency’s catalogue of vulnerabilities with evidence of active exploitation in the wild. An entry there means someone is using it, not that someone might.
Censys says more than 294,000 distinct public IP addresses now expose one of 43 detected AI and LLM tools to the internet, up from roughly 183,000 in October 2025, which it reports as a rise of over 60%. It is a striking figure, and on its own it tells you almost nothing about whether you are exposed.
What Censys actually counted
Censys’s figure comes from a preview of its 2026 State of the Internet Report, which it says is coming this autumn. The precise description is worth keeping intact: publicly detectable AI/LLM tools observed on distinct public IP addresses.
It is not 294,000 vulnerable systems. It is not 294,000 production deployments, or 294,000 organisations. One organisation can account for many addresses; one address can front several tools; a detectable instance may be a deliberate public endpoint, a demo, a honeypot, or fully patched.
Nor does it show that exposure is outpacing adoption, which is the reading the chart invites. Answering that would need a ratio — publicly exposed deployments of a defined tool, over all deployments of that same tool — and Censys does not publish the denominator. Enterprise AI-adoption surveys cannot fill the gap, because they count organisations reporting AI use, or spend, or staff with access. Those measures share no denominator with an internet-wide scan.
The preview also does not include the methodology: the detection rules, the false-positive rate, how coverage changed between October 2025 and now, or which 43 tools are in the set. A count that grows can mean more exposure or better detection, and from the outside you cannot separate the two. I will read the full report when it lands. Until then, the number should send you to look at your own estate. It tells you nothing about it.
The number underneath it that I would act on
Here is the specific thing I would act on.
On 24 April 2026, the LiteLLM maintainers published an advisory for a SQL injection in the proxy’s API-key verification. The NVD record describes the mechanism plainly: from version 1.81.16 to before 1.83.7, a database query used during proxy API-key checks mixed the caller-supplied key value into the query text instead of passing it as a separate parameter. An unauthenticated attacker could send a crafted Authorization header to any LLM API route — POST /chat/completions, for instance — and reach that query through the proxy’s error-handling path.
It scores 9.8 on CVSS v3.1 and 9.3 on v4.0. Both say critical. It was patched in 1.83.7.
CISA added it to the Known Exploited Vulnerabilities catalogue on 8 May 2026, with a remediation due date of 11 May for federal agencies — a three-day window, which is CISA’s way of saying this is not theoretical. The catalogue records the impact as reading data from the proxy’s database and potentially modifying it, leading to unauthorised access to the proxy and the credentials it manages. Its ransomware-campaign field reads “Unknown,” and no public primary source names an actor or a campaign. Exploitation is confirmed; attribution is not.
This is the second time in five months that LiteLLM has been the story for reasons its users did not choose. In April I wrote about the TeamPCP compromise of the LiteLLM package on PyPI, which was a supply-chain problem. This one is a code defect in the proxy itself. Different failure, same lesson about where a small piece of AI plumbing sits in a stack.
Where Censys overshoots its own source
Censys’s write-up says of LiteLLM: “as a unified LLM proxy, a single compromise exposes API keys for every upstream model provider.”
That is a stronger claim than the primary advisory makes, and I would not carry it forward. The advisory and the CVE record both say the credentials the proxy manages. What that amounts to is a property of the individual deployment: which providers are configured, what the database holds, whether secrets live in the proxy’s store or in an external secret manager, and what restrictions sit on the keys themselves. A LiteLLM instance wired to one provider with a scoped, rate-limited key is not the same incident as one holding unrestricted keys for five.
The gap between those two formulations is the difference between a finding and a headline. It is a small overreach and it points the right way — but if you are making a case to a security lead, quote the advisory rather than the vendor blog summarising it.
Censys also reports that LiteLLM’s exposure nearly doubled over the same nine months, up 97%. That figure I would use, attributed, because it is Censys measuring the thing Censys measures.
Langflow, briefly, because it is the same shape
Censys says Langflow grew 169% in the nine-month window and has accumulated 18 CVEs across 2024–2026, 14 of them scoring above 8.0, including four CISA KEV entries. Attribute all of that to Censys; it is not an independently audited tally.
The confirmed example is CVE-2026-33017. In versions before 1.9.0, a POST /api/v1/build_public_tmp/{flow_id}/flow endpoint let anyone build public flows without authenticating, and when an optional data parameter was supplied it used attacker-controlled flow data — arbitrary Python in node definitions — instead of the stored flow, passing it to exec() with no sandboxing. Unauthenticated remote code execution, fixed in 1.9.0, added to CISA KEV on 25 March 2026.
The point is not a CVE inventory. It is that visual AI workflow tools tend to hold code-execution paths, credentials and network reachability in one process, and they were built for a workbench rather than an open port.
What to do with this
Treat an AI gateway as a concentrated security boundary, which is what it is. The convenience and the blast radius come from the same decision.
- Patch. LiteLLM 1.83.7 or later. Langflow 1.9.0 or later.
- Get it off the public internet. Management and proxy interfaces belong behind private networking, a VPN, an identity-aware proxy, or tightly controlled ingress. Public reachability should be a decision someone made and can defend, rather than a default nobody revisited.
- Rotate, if it was exposed. If an affected LiteLLM deployment was publicly reachable while unpatched, rotate the provider keys it held or could reach. Patching stops repeat exploitation; it cannot recall a secret that was already copied.
- Segment credentials so one proxy database is not a complete inventory of your provider access. This is the control that decides whether Censys’s version of the impact or the advisory’s version describes your incident.
- Watch the right signals: failed authentication, malformed authorisation headers, unexpected database errors, and anomalous model-provider usage.
The 294,000 will get quoted for the rest of the year. The useful question it should prompt is much smaller: is your AI gateway reachable from the internet, and do you know which version it is running?