Skip to content
Today
Sections

Security Independently confirmed2 publishers 3 min read Published Updated

Whoever holds a LiteLLM master key reads every provider key and the host's IAM credentials

Wiz found 294 of 3,074 internet-facing LiteLLM gateways answering admin requests in February, and two thirds of those had no key set at all rather than the documented sk-1234. That changes what needs fixing.

The Watch · Security desk

Send a correction

Illustration accompanying Whoever holds a LiteLLM master key reads every provider key and the host's IAM credentials
Generated illustration

What happened

  • Wiz Research scanned Shodan in February, found 3,074 internet-facing LiteLLM gateways, and 294 of them granted administrator access to sk-1234, the example master key in the project's own setup guide.
  • In 191 of those 294 no master key was configured at all, so any value worked, and before release 1.82.0-stable a keyless gateway treated every incoming request as an administrator.
  • An administrator on one of these gateways can read every model provider API key stored on it, and in Wiz's tests the same access reached the cloud IAM credentials of the host machine.
  • Wiz describes CVE-2026-59821 as root-level code execution and shows uid=0(root) inside the container, while LiteLLM's advisory for the same behaviour rates it Low at CVSS 2.1 because it needs a privileged account.

Why it matters

  • What it costs cost The remediation price here is one credential rotation with no upgrade window, and it removes every step in Wiz's chain that starts from holding the key.
  • Who's exposed exposure Provider keys lifted from a single gateway are spendable: model workloads run on the victim's invoice, and the host role extends the reach past the AI stack into the cloud account.
  • What it limits constraint Because LiteLLM's security policy puts setup mistakes such as an unset master key outside scope, operators will not get an advisory or a CVE for the condition behind most of the 294 hits, so detection falls to their own scanning.
  • What doesn't add up contradiction Wiz's sandbox-only reassurance for post-1.82.0 deployments sits against the project's own May advisory, and taking the advisory at its word moves the safe release two minor versions later.

Subtract the 191 gateways that had no master key at all, and the documented value was in place on 103 of the 294 that answered, which is 3.4 percent of the 3,074 scanned [2][3][24]. The other 65 percent of the accepting set had nothing to guess [25]. The distinction decides which repair helps. Rewriting the setup guide covers the smaller share; the rest comes from a design choice, because the master key is both the admin credential and the switch that turns authentication on, so a gateway that starts without one granted full admin rights to every inbound request before 1.82.0-stable [6][7].

Administrator is the whole gateway. It can reach internal tools over the Model Context Protocol [8], and it usually inherits the cloud permissions of the workload it runs in [9]. An admin can also create a pass-through route that forwards requests to any URL, and the target is not checked against localhost, private address ranges, or the instance metadata service [11]. IMDSv2 does not close that door, because LiteLLM forwards any header carrying an x-pass- prefix with the prefix removed, which is how Wiz supplied the token headers IMDSv2 requires [12]. That chain has no CVE and no fix. Wiz's own reading is that the feature is arguably working as intended, since the project's threat model treats administrators as trusted [14], and no one has reported it used against a live deployment [13].

The version floor is the part worth checking. Both descriptions of CVE-2026-59821 concern the guardrail create and update endpoints, which skipped the sandbox and pattern checks before 1.82.0-stable and would run submitted Python inside the container [18]. Wiz's report says that after 1.82.0 an attacker with the default key is confined to a sandbox [27]. LiteLLM's own advisory from May, CVE-2026-40217, says that sandbox could be escaped with bytecode techniques by running code in the proxy process, which the advisory notes runs as root in the default Docker image, across versions from 1.81.8 up to but not including 1.83.10, reachable with a proxy-admin credential [28][29]. The master key is that credential [29]. For a gateway whose key is printed in the documentation, the fixed release is 1.83.10, not 1.82.0 [30].

Whether any of this improved since February is not knowable from the published data. A second scan in August returned more than 85,000 instances, but Wiz assesses most as honeypots or test systems, so it is not comparable to the 3,074 and there is no current figure [21]. What is known is that the guide still shipped sk-1234 on September 9, roughly seven months after the scan, above the comment telling operators to replace it with a long random value [22][26]. Rotating that key needs no upgrade and removes every step in Wiz's report that depends on holding it [20].

What to watch

  • Whether the setup guide drops sk-1234 for a generated value, which would separate new deployments from the documented default.
  • A repeat scan with honeypots and test systems filtered out, producing a count comparable to February's 3,074.
  • The first report of the pass-through-to-metadata technique used against a live deployment rather than in a lab.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence62
Adoption58
Hype gap+25
Incentives55
Confidence64
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    Nearly one in ten of the internet-facing LiteLLM servers Wiz Research scanned in February accepted sk-1234, the example admin key in LiteLLM's own setup guide.

    Reported Supported Source: Wiz Research, reported by thehackernews.comView cited source
  2. [2]

    Wiz ran one scan and found 3,074 LiteLLM gateways on Shodan in February; 294 of them accepted the key.

    Reported Supported Source: Wiz ResearchView cited source
  3. [3]

    In 191 of the 294 gateways, no master key was set at all, so they would have accepted anything; the rest had the setup guide's value left in place.

    Reported Supported Source: Wiz ResearchView cited source
  4. [4]

    LiteLLM is an open-source AI gateway that sits between a company's applications and the model providers it pays for, and the master key is the gateway's administrator credential.

    Reported SupportedView cited source
  5. [5]

    Anyone holding the master key can read every model provider's API key stored on the server, and in Wiz's tests it also reached the cloud IAM credentials of the machine the gateway runs on.

    Reported Supported Source: Wiz ResearchView cited source
  6. [6]

    The LiteLLM master key does two jobs at once: it is the admin credential and the switch that enables authentication.

    Reported SupportedView cited source
  7. [7]

    Before version 1.82.0-stable, a LiteLLM gateway that started without a master key granted every incoming request full admin rights.

    Reported SupportedView cited source
  8. [8]

    The gateway can hold an API key for every provider it routes to, see every prompt and reply passing through, and connect to internal tools via the Model Context Protocol.

    Reported SupportedView cited source
  9. [9]

    A LiteLLM gateway usually runs with the cloud permissions of the workload it is deployed in.

    Reported SupportedView cited source
  10. [10]

    Stolen provider keys alone let an attacker run model workloads on the victim's bill, an abuse known as LLMjacking.

    Reported SupportedView cited source
  11. [11]

    LiteLLM lets an administrator create a pass-through endpoint that forwards requests to any URL, and the target URL is not checked against private address ranges, localhost, or cloud metadata addresses.

    Reported SupportedView cited source
  12. [12]

    Switching to IMDSv2 does not stop the pass-through technique: LiteLLM documents that any header sent with an x-pass- prefix is passed to the target with the prefix removed, and Wiz used that to send the headers IMDSv2 requires.

    Reported Supported Source: Wiz ResearchView cited source
  13. [13]

    No source reports anyone using the pass-through-to-metadata technique against a real deployment; it is a demonstration and needs admin access first.

    Reported SupportedView cited source
  14. [14]

    Wiz says the pass-through feature is arguably working as intended, because LiteLLM's threat model treats administrators as trusted; it has no CVE and no fix.

    Reported Supported Source: Wiz ResearchView cited source
  15. [15]

    LiteLLM's published security policy lists attacks that need a setup mistake, such as not setting a master key, as explicitly not in scope and not treated as vulnerabilities.

    Reported Supported Source: LiteLLM security policyView cited source
  16. [16]

    Wiz calls CVE-2026-59821 post-authentication code execution at root level and shows a test returning uid=0(root) inside the gateway container.

    Reported Supported Source: Wiz ResearchView cited source
  17. [17]

    LiteLLM's advisory for CVE-2026-59821 rates it Low, 2.1 on the CVSS scale, describing a flaw that requires a high-privilege account.

    Reported Supported Source: LiteLLM advisoryView cited source
  18. [18]

    Before 1.82.0-stable, the endpoints that create and update custom code guardrails skipped the sandbox and pattern checks the test endpoint applied, so anyone who could reach them could submit Python that ran inside the container.

    Reported SupportedView cited source
  19. [19]

    LiteLLM's advisory adds that a deployment with no master key treated callers as proxy administrators, which is what put the guardrail endpoints within reach.

    Reported Supported Source: LiteLLM advisoryView cited source
  20. [20]

    Changing the key needs no upgrade, and it closes every path in Wiz's report that depends on holding it.

    Reported SupportedView cited source
  21. [21]

    A second Wiz scan in August found more than 85,000 instances, but Wiz says most appear to be honeypots or test systems, so the two counts cannot be compared and there is no current figure.

    Reported Supported Source: Wiz ResearchView cited source
  22. [22]

    As of September 9, LiteLLM's setup guide still uses sk-1234, above a comment telling operators to replace it with a long random value before any real use.

    Reported SupportedView cited source
  23. [23]

    The 294 accepting gateways are 9.6 percent of the 3,074 Wiz found in February.

    Derived Supported
  24. [24]

    103 of the 294 accepting gateways had the documented sk-1234 value in place, which is 3.4 percent of the 3,074 scanned.

    Derived Supported
  25. [25]

    Gateways with no master key set were 65 percent of the 294 that accepted admin requests.

    Derived Supported
  26. [26]

    About seven months separate Wiz's February scan and September 9, the date on which the setup guide still used sk-1234.

    Derived Supported
  27. [27]

    Wiz's report states that after 1.82.0 an attacker with the default key could only run code within a sandbox, and LiteLLM's own record does not support that for every release.

    Reported Contested Source: Wiz Research report and LiteLLM advisoriesView cited source
  28. [28]

    A separate LiteLLM advisory published in May, CVE-2026-40217, says the sandbox could be escaped using bytecode techniques by running code in the proxy process, which the advisory notes runs as root in the default Docker image.

    Reported Contested Source: LiteLLM advisory for CVE-2026-40217View cited source
  29. [29]

    CVE-2026-40217 covers versions from 1.81.8 up to, but not including, 1.83.10, and reaching the endpoint needs a proxy-admin credential; the master key is that credential.

    Reported Contested Source: LiteLLM advisory for CVE-2026-40217View cited source
  30. [30]

    For a deployment where the master key is the documented default, the release that fixes both reported code execution paths is 1.83.10 rather than 1.82.0, because CVE-2026-40217 remains exploitable with a proxy-admin credential up to 1.83.10.

    Derived Contested

Sources

2 independent publishers whose own reporting we read for this story.

  1. thehackernews.com

    2 articles · September 10, 2026

    Nearly 1 in 10 Exposed LiteLLM Gateways Accepted the Example "sk-1234" Admin Key
  2. wiz.io

    1 article · September 9, 2026

    Off Guard: Breaking LiteLLM from authentication bypass to cloud compromise

Topics and entities

Topics

Entities