What happened
On 9 September 2026, Wiz published its LiteLLM authentication, code-execution and cloud-credential research. On 10 September 2026, The Hacker News independently reported the exposure counts and highlighted disagreement over safe-version boundaries. Agent or framework: LiteLLM is an open-source AI gateway providing a unified OpenAI-compatible interface. Underlying model: No single underlying model is fixed; LiteLLM routes requests to more than 100 model providers.
In February 2026, Wiz performed the scan that produced the 3,074-instance sample. Wiz found that 294 of 3,074 public LiteLLM instances, or 9.6%, accepted the example master key sk-1234 or required no authentication. The Hacker News reports that 191 of the 294 exposed instances had no master key configured and therefore accepted any supplied value. An August 2026 scan returned more than 85,000 apparent instances, but Wiz said honeypots and test systems made it incomparable with the February sample.
Operator configuration: Exposed deployments either retained sk-1234 or started without a master key. Mechanical action: In no-auth mode, LiteLLM granted callers PROXY_ADMIN; on vulnerable versions, submitted custom guardrail code could execute in the container. Wiz states that CVE-2026-59821 affects versions before 1.82.0 and can yield root access to the default container when combined with the default master key.
The Hacker News notes that CVE-2026-40217 affects versions from 1.81.8 up to, but not including, 1.83.10 and can escape the custom-code sandbox. The cited sources did not publish a threat-actor infrastructure set tied to the scanned LiteLLM instances. Attribution posture: Wiz did not attribute the exposed LiteLLM instances or tested paths to a threat actor.
Why this matters now
The vulnerabilities themselves were fixed earlier; the materially new evidence is the exposure study and configuration finding. Nearly one in ten genuine public instances in the February sample accepted the example master key or no authentication, converting an old software issue into a current asset-discovery and secret-containment decision.
LiteLLM sits between applications and model providers, concentrating provider keys, routing policy, budgets, prompts and connections to tools. Treating it as ordinary developer middleware understates the privilege of the gateway and the impact of a default credential or unauthenticated administrator role.
The reporting also exposes uncertainty in version-only closure. Wiz describes version 1.82.0 as the improvement boundary for the guardrail path it tested. The Hacker News reports version 1.83.10 as the upper boundary of the separate sandbox-escape range. Configuration, reachability and all relevant advisories must be assessed together.
The published prevalence is not a current internet census. Security leaders should use it to justify internal discovery, not to estimate their probability of compromise. An exposed gateway accepting sk-1234 is a deterministic control failure regardless of the global percentage.
The decision for security leaders
Classify LiteLLM as a privileged AI control plane. Assign ownership for authentication, internet exposure, secret storage, provider access, logging, upgrades and Model Context Protocol connections rather than leaving responsibility with individual development teams.
Treat confirmed default-key or no-authentication exposure as a credential-containment event. Determine what the gateway process could read, which provider and cloud identities were available and whether administrator endpoints or custom-code functions were invoked.
Do not close solely on version 1.82.0. Reconcile configuration and all relevant advisories, including the separate range below 1.83.10, then validate that public access, administrator behaviour and reachable credentials match the approved architecture.
Evidence of closure
- Cloud inventory accounts for every LiteLLM deployment and owner.
- Authentication testing rejects sk-1234 and unauthenticated administrator requests.
- Network evidence confirms only approved clients can reach each gateway.
- Rotation records cover every credential reachable from exposed instances.
The Security.io assessment
The 9.6% figure is useful evidence of a control pattern, not a present-day global exposure rate. The February sampling date and the incomparable August results prevent a defensible claim about how many genuine vulnerable systems remain online now.
The most important issue is concentration of privilege. A gateway that stores provider keys and runs with cloud permissions can turn one default credential into model abuse, secret theft, infrastructure access and prompt or policy exposure.
The conflicting version narrative reinforces evidence-based closure. A patched package with an unchanged default key and unnecessary internet exposure remains unsafe, while a securely configured newer deployment still needs monitoring because its role is inherently privileged.
Questions for the morning meeting
- Where is LiteLLM deployed across cloud and development environments?
- Does any deployment accept sk-1234 or unauthenticated requests?
- Which provider and cloud credentials are reachable from each gateway?
- Which versions remain inside either published code-execution range?