Introduction

On May 8, 2026, the US Cybersecurity and Infrastructure Security Agency added a vulnerability in BerriAI's LiteLLM to its Known Exploited Vulnerabilities catalog. CISA does not list theoretical risks. It adds a CVE only when there is reliable evidence that attackers are exploiting it in the wild - right now. The flaw, CVE-2026-42208, is among the first vulnerabilities in a dedicated AI gateway to reach that bar. It will not be the last. And for most organizations, the hardest part of responding to it is not patching. It is finding out whether they are even running it.

What LiteLLM Is, and What the Flaw Does

LiteLLM is a widely used open-source library that gives applications a single, unified way to call many different model providers - OpenAI, Anthropic, and others - through one interface. It is frequently deployed as a proxy that centralizes API credentials. CVE-2026-42208 is a critical, pre-authentication SQL injection, carrying a CVSS score of 9.3, in the proxy's API-key verification path: a caller-supplied key value was concatenated directly into a database query instead of being passed as a separate parameter. An unauthenticated attacker can send a crafted authorization header to a routine endpoint and read or modify the proxy's database - including the provider credentials it stores. Compromise it, and you have effectively lost every connected AI provider account at once.

The timeline is the part that should worry defenders most. The vulnerability was disclosed around April 24, 2026. Real-world exploitation was observed within roughly 36 hours. CISA added it to the KEV on May 8 and set a federal remediation deadline of May 11 under Binding Operational Directive 22-01. The window between publicly known and actively attacked was less than two days.

Why Your VA Scan and Pen Test Missed It

Traditional vulnerability tooling was built for operating-system packages and network-listening services. LiteLLM is neither, which is precisely why it slips through the gaps.

• It is a Python library, not a service. It runs inside the application process, so external network scanners such as Nessus, Qualys, or OpenVAS have nothing to fingerprint from the outside.
• It is transitive - a dependency of a dependency. LangChain, LangGraph, AutoGen, and CrewAI all pull it in. You can be running it without ever having imported it directly, and a quick package list on the parent will not surface it as a direct entry.
• It hides inside containers and conda environments. A base image built once in 2024 and never rebuilt can still be running a vulnerable version in production today, one layer below where most asset inventories stop.
• Pen tests probe endpoints, not imports. Unless the tester knows the specific exploit signature and the application exposes it, the test passes while the vulnerable library sits there - present, vulnerable, and invisible.

We Have Seen This Pattern Before

Three years ago, a vulnerability buried in a Java logging library that almost nobody had inventoried set off a global scramble. The defining feature of the Log4Shell response was not the difficulty of patching - the fix itself was straightforward. It was the difficulty of finding every place the library was running. The organizations that recovered fastest were the ones that already had a software bill of materials and could answer do we have it, and where, in hours instead of weeks. LiteLLM is the same pattern, arriving now in the AI dependency layer.

The Answer Is an Inventory You Maintain Before the Incident

Responding well to a KEV entry is fundamentally a discovery problem, and discovery is far cheaper done in advance than under fire. Two complementary inventories close the gap. A software bill of materials, or SBOM - direct and transitive dependencies with exact versions, in a standard format such as CycloneDX or SPDX - answers the question do we have it. An AI bill of materials extends that to the things SBOMs were never designed to capture: the models a library routes to, the agents and tools wired around it, and the workflows that depend on it. Together they let you answer not just whether LiteLLM is installed, but where it lives, what calls it, and what breaks if you patch or remove it. Correlate that inventory continuously against the KEV catalog and the next AI-library entry becomes a minutes-long triage rather than a multi-week forensics project.

Conclusion

LiteLLM's appearance on the KEV is a warning shot, not an anomaly. AI infrastructure - gateways, orchestration libraries, vector stores, agent frameworks - is now valuable enough, and widely enough deployed, to become a sustained source of actively exploited vulnerabilities. The deciding factor next quarter will not be how fast you can patch. It will be whether you already know what you are running. Build the inventory before you need it.