What Happened
Between late 2025 and early 2026, attackers discovered they could chain two vulnerabilities in LiteLLM—an open-source AI gateway used to route requests across multiple LLM providers—to achieve unauthenticated remote code execution. CVE-2026-42271 (CVSS 8.8) in LiteLLM itself combined with CVE-2026-48710 in its Starlette dependency created a complete authentication bypass. The Qilin ransomware group weaponized this chain in active campaigns. On June 9, 2026, CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities catalog, confirming exploitation in the wild.
Timeline
- Late 2025: Researchers identify path traversal vulnerability in Starlette (CVE-2026-48710).
- December 2025 - January 2026: Attackers discover they can chain Starlette's path traversal with LiteLLM's authentication logic to bypass security controls entirely.
- February - May 2026: Qilin ransomware operators exploit the chain against organizations running vulnerable LiteLLM instances (versions 1.74.2 through 1.83.6).
- June 9, 2026: CISA adds CVE-2026-42271 to KEV catalog, mandating federal agencies patch within 21 days.
- Current state: Organizations running unpatched LiteLLM instances face active exploitation targeting their entire AI provider credential stack.
Which Controls Failed or Were Missing
Dependency vulnerability management: Your team may have tracked LiteLLM patches but missed that Starlette—a transitive dependency—introduced its own exploitable flaw. Compromised organizations updated LiteLLM but ran outdated Starlette versions through their package manager's dependency resolution.
Authentication boundary testing: Standard penetration tests validated LiteLLM's authentication under normal conditions but didn't test whether an attacker could manipulate path handling in the underlying web framework. The exploit worked by sending specially crafted requests that Starlette processed before LiteLLM's auth middleware.
Credential segmentation: LiteLLM acts as a central gateway storing API keys for multiple providers. Compromising one instance gave attackers access to the entire AI provider stack. Organizations treated the gateway as a trusted internal service without implementing defense-in-depth for credential exposure.
Patch prioritization: Security teams saw CVE-2026-42271's 8.8 CVSS score but classified it as "high" rather than "critical" because initial advisories didn't emphasize the authentication bypass. They scheduled it for the next monthly patch cycle rather than emergency deployment. By the time CISA added it to KEV, some organizations had already been compromised for weeks.
What the Relevant Standards Require
NIST 800-53 Rev 5 SI-2 (Flaw Remediation): Requires organizations to install security-relevant software updates within time periods defined by the organization based on risk assessment. For vulnerabilities in the KEV catalog, federal agencies must patch within 21 days. Your organization should define similar SLAs—if CISA says it's actively exploited, your monthly patch window is too slow.
PCI DSS v4.0.1 Requirement 6.3.3: Mandates that security vulnerabilities are identified using reputable sources and that risk rankings are assigned to vulnerabilities based on industry practices. This includes your dependencies. If you're only monitoring LiteLLM releases and not Starlette, you're not compliant.
ISO/IEC 27001:2022 Control 8.8 (Management of Technical Vulnerabilities): Requires organizations to obtain information about technical vulnerabilities of information systems in use, evaluate exposure to such vulnerabilities, and take appropriate measures. "Information systems in use" includes your dependency tree. You need tooling that alerts you when a transitive dependency introduces a new CVE.
OWASP ASVS v4.0.3 Section 14.2 (Dependency): Level 2 requires that all components are identified, and known vulnerable components are not used. Level 3 adds that a Software Bill of Materials (SBOM) is maintained and updated when dependencies change. If you can't answer "what version of Starlette are we running?" in under 60 seconds, you're not meeting Level 2.
SOC 2 Type II CC7.1 (System Monitoring): Requires monitoring system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors. This includes monitoring for new vulnerabilities in deployed components. Your SOC 2 auditor should be asking how you track dependency vulnerabilities.
Lessons and Action Items for Your Team
Build an SBOM for every service: Run pip-audit or safety in your CI pipeline. Export SBOMs in CycloneDX or SPDX format. Feed them into your vulnerability scanner. You need to know that LiteLLM depends on Starlette 0.x before the exploit drops, not after.
Define KEV response SLAs: If a vulnerability hits CISA's KEV catalog, you patch within 72 hours or you take the service offline. No exceptions. Build this into your incident response playbook. KEV means "attackers have working exploits"—your monthly patch cycle doesn't apply.
Test authentication boundaries at the framework level: Your pentest should include path traversal attacks against the web framework itself, not just your application logic. Test with malformed paths, Unicode normalization bypasses, and double-encoded characters. If your gateway sits in front of authentication, test whether an attacker can route around it.
Segment credentials by service: Don't store all your LLM provider keys in one gateway instance. If you must centralize, implement per-service credential scoping. An attacker who compromises your customer-facing chatbot gateway shouldn't get keys to your internal code analysis LLM.
Monitor for exploitation indicators: Watch for requests with unusual path patterns to your LiteLLM endpoints. Log all authentication failures with full request context. Set up alerts for requests that hit admin endpoints without valid auth tokens. The exploit leaves traces—you need to be looking for them.
Automate dependency updates for security patches: Use Dependabot or Renovate to open PRs when security updates ship. Configure them to auto-merge patch versions for critical dependencies after your test suite passes. Waiting for a human to manually bump Starlette from 0.38.1 to 0.38.2 is how you end up on the victim list.
The LiteLLM incident demonstrates that your application is only as secure as your least-maintained dependency. Compliance frameworks require you to track those dependencies—now you know why.
