LiteLLM SQLi exploitation accelerating: 36-hour weaponisation window exposes pre-auth data access risk

LiteLLM's rapid exploitation demonstrates the accelerating threat cycle for open-source AI tooling. The 36-hour window from disclosure to active weaponisation is substantially faster than traditional vulnerability adoption rates, suggesting either automated scanning by threat actors or targeted reconnaissance of LLM infrastructure. Pre-authentication SQL injection in API gateways is particularly severe because these systems typically route requests across multiple LLM providers whilst storing authentication tokens, rate-limit data, and usage logs.

The CVSS 9.3 score reflects the absence of authentication requirements combined with high attack complexity. Attackers can construct malicious requests that inject SQL directly into database queries without needing valid credentials. The vulnerability likely exists in query string parsing, possibly in the proxy request handling layer where LiteLLM normalises API calls from diverse LLM providers. The ability to modify underlying data suggests attackers can poison authentication tokens, escalate privileges across the gateway, or inject malicious configurations into downstream LLM calls.

Organisations using LiteLLM as a centralised gateway for Claude, GPT, or other provider APIs face immediate exposure to credential compromise. An attacker exploiting this flaw can exfiltrate API keys for all connected services, harvest user session tokens, and potentially manipulate logs to cover their tracks. Supply chain risk is amplified in multi-tenant deployments where a single compromised gateway can expose API keys tied to hundreds of applications.

Defenders should immediately audit deployment logs for suspicious SQL patterns in request parameters, particularly in proxy routes handling authentication or configuration endpoints. Organisations unable to patch within hours should isolate LiteLLM instances behind additional WAF rules filtering for common SQLi signatures or temporarily disable external access. The broader lesson is that LLM gateways now represent critical attack surface equivalent to API management platforms like Kong or Ambassador. Security teams must treat these systems with the same rigour as production databases rather than viewing them as transparent proxies.

The rapid exploitation timeline suggests threat actors are actively scanning for LiteLLM instances on the public internet. Given that many organisations deploy LiteLLM to consolidate multiple expensive API subscriptions, the economic motivation for this attack is high. This incident reinforces that tooling designed to abstract authentication across multiple services requires security hardening equivalent to dedicated secrets management platforms.