Yes. CISA added CVE-2026-42208 to its Known Exploited Vulnerabilities catalogue on 8 May 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. BerriAI LiteLLM contains a SQL injection vulnerability that allows an attacker to read data from the proxy’s database and potentially modify it, leading to unauthorized access to the proxy and the credentials it manages.
What the KEV listing means for a BerriAI LiteLLM SQL injection
CISA placing a vulnerability in KEV is a strong operational signal, because it means the issue has crossed from theoretical exposure into confirmed exploitation risk. For practitioners, that changes the priority from “track for later” to “treat as an active attack path,” especially when the affected system brokers access to other systems or stores sensitive credentials.
For a SQL injection like this one, the first question is not whether the flaw exists in isolation, but whether the LiteLLM proxy is reachable, whether the database it fronts contains secrets or access records, and whether the proxy has enough privilege for an attacker to read or alter those records. That determines whether exploitation is a simple data exposure event or a broader compromise of the platform’s trust boundary.
When a KEV-listed flaw sits in a proxy or gateway layer, the exposure often extends beyond the application itself. If the database behind the proxy stores credentials, API keys, session material, or tenant metadata, a successful injection can turn one application weakness into downstream access to multiple services.
How SQL injection changes the exposure profile
SQL injection is dangerous here because it attacks the application’s data boundary, not just its input handling. An attacker who can shape queries may be able to enumerate records, exfiltrate configuration data, or modify rows that control authentication, authorization, or routing decisions.
If the proxy’s database includes the credentials it manages, the impact can extend into credential theft and service impersonation. That matters because the attacker is not merely reading application data, they may be collecting reusable secrets that unlock other systems, APIs, or automation paths.
Where possible, confirm whether the vulnerable instance uses a direct database connection, what database account privileges it holds, and whether the application uses stored procedures, ORM abstraction, or raw SQL. Those implementation details strongly influence whether the injection is read-only, write-capable, or capable of altering security-relevant state.
What to do when you cannot patch immediately
If remediation is delayed, reduce exposure by narrowing network reachability, restricting who can reach the proxy, and placing the most sensitive backend data out of immediate reach. Compensating controls are strongest when they reduce both the chance of exploitation and the value of the data an attacker could reach if exploitation succeeds.
Also verify whether the proxy is logging suspicious query patterns, unexpected error bursts, or unusual database access from the application account. That will not stop exploitation, but it can help you distinguish routine traffic from active probing and identify a compromise window.
For a practical triage path, Zero-Day and Exploited Vulnerabilities Guide is the most direct playbook for KEV-driven response, and CISA Known Exploited Vulnerabilities Catalog remains the authoritative source for exploitation status and required remediation timing.
How to tell whether exploitation already happened
Once a SQL injection is confirmed or suspected, the main forensic question is whether the attacker only touched the proxy, or used it to pivot into the data it controls. Check database audit records, application logs, and any changes to privileged accounts, access tokens, or routing configuration that the proxy stores or can influence.
You should also look for evidence of secondary abuse, such as new database users, changed permissions, unusual reads of credential tables, or follow-on authentication events against systems that depend on the proxy. Those are stronger indicators of material compromise than the injection attempt itself.
Where the proxy manages sensitive secrets, treat compromise assessment and secret rotation as part of the same response. A read-capable SQL injection can still expose secrets even if no destructive change occurred, and those exposed values may remain useful to an attacker after the initial flaw is fixed.
Risk and Threat Considerations
This is a high-consequence exposure because the vulnerable component is not just a web endpoint, it is a proxy that may mediate access to databases and managed credentials. If exploited, the attacker can use the injection to steal data, manipulate records, or harvest secrets that enable broader compromise.
Failure mechanism: The attacker abuses unsanitised SQL input to execute database queries through the application, then targets whatever sensitive records or access material the proxy can reach.
Impact: The likely outcomes are unauthorized data access, credential exposure, tampering with application state, and possible lateral movement into adjacent systems that trust the proxy or its stored secrets.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | SQL injection is primarily prevented by input handling and query safety. |
| V4 — API and Web Service | LiteLLM is a service proxy that exposes application-facing request handling. | |
| Recommendation — Enforce query parameterization and input validation to prevent SQL injection paths. Harden service endpoints and validate all request parameters before they reach SQL execution. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The issue is an input-driven injection flaw that requires validation controls. |
| AU-6 — Audit Review, Analysis, and Reporting | Active exploitation and post-compromise review depend on logging and detection evidence. | |
| Recommendation — Validate application input before it is used in SQL queries or other interpreters. Review logs for anomalous queries, access patterns, and database privilege changes. | ||
| CIS Controls v8 | 5 — Account Management | The exploit may expose credentials or accounts managed by the proxy. |
| Recommendation — Limit, inventory, and rotate accounts and secrets that the proxy can access. | ||
Practitioner Guidance
What to prioritise: Treat KEV status as an exploitation indicator, then rank the affected LiteLLM instance by the sensitivity of the backend data it can reach. A proxy that can read credentials or high-value metadata deserves immediate containment even before full remediation is complete.
What to verify: Confirm the database account privileges, the sensitivity of stored records, and whether any secrets or access tokens were exposed in logs, tables, or configuration stores. If the application can alter security-relevant rows, assume the blast radius is larger than a simple data leak.
Practitioner takeaway: For exploited SQL injection, the key decision is not only whether to patch, but whether the exposed data path can be trusted after patching; if the proxy handled secrets, rotation and compromise review should move in lockstep with remediation.