Wiz Research: Nearly 1-in-10 Exposed LiteLLM Gateways Accepted the Example "sk-1234" Admin Key

One example admin key from a setup guide, nearly ten percent of gateways accepting it. LiteLLM hygiene lands this week.

Nearly one in ten internet-facing LiteLLM gateways that Wiz Research scanned in February 2026 still accepted sk-1234, the example administrator credential printed in LiteLLM’s own setup guide, according to reporting published September 10 by The Hacker News.

LiteLLM (open-source AI gateway) is a widely deployed proxy that routes an organization’s traffic to OpenAI, Anthropic, AWS Bedrock, Azure, and dozens of other model providers. That role makes its administrator credential one of the most valuable keys on a network, because whoever holds it can reach every provider account wired into the gateway. The fix here is not complicated and does not need a patch: remove the example key, set a unique master secret, and rotate any admin key that was ever left at a default. What follows is what Wiz documented, why an example key ended up live on production servers, and the exact checks a LiteLLM operator should run today.

What Wiz Documented

Wiz Research scanned internet-facing LiteLLM servers in February 2026 and found that nearly 10 percent of them accepted sk-1234 as a working administrator credential, The Hacker News reported on September 10. Put plainly: a well-known string that anyone can read in public documentation authenticated as an admin on roughly one in ten exposed gateways.

The important framing for a defender is that this is a configuration and credential-hygiene finding, not a software flaw. There is no CVE to apply, because nothing in LiteLLM is broken in the way a vulnerability report describes. The gateways that accepted the key were deployed with the example credential still in place and then reachable from the public internet. That distinction changes the response. There is nothing to patch and wait on. The work is to check your own configuration, confirm the default key no longer authenticates, and rotate it if it ever did.

Our assessment, distinct from the reported finding: a rate near 10 percent across an internet-wide scan is high enough to treat every self-hosted LiteLLM deployment as guilty until verified, especially any instance stood up quickly for a proof of concept and never revisited. The reported number is Wiz’s; the recommendation to assume exposure until you have checked is ours.

The sk-1234 Example Key and Its Setup-Guide Origin

The reason this specific string keeps turning up is that sk-1234 is the placeholder master key used in LiteLLM’s own setup guide. It is short, memorable, and easy to paste into a quickstart so a new user can get the gateway answering requests in a few minutes. That is exactly what a getting-started example is supposed to be.

The trouble is the path from quickstart to production. An operator copies the example, confirms the gateway works, and then moves on to the next task without swapping the placeholder for a real secret. The example key becomes the live administrator credential, and because it is documented in public, it is also the first thing an internet-wide scan will try. The gap is not the guide teaching the value. The gap is deployments that never replaced it before going online.

Whether LiteLLM has since revised its setup guide to drop or obscure the example key is not confirmed in the reporting. Even if the documentation changes tomorrow, the servers already running with the placeholder in place do not fix themselves. The remediation lives with each operator, not with the project.

The AI-Gateway Attack Surface Implications

An AI gateway is a credential concentrator by design. Its whole job is to hold provider keys in one place and route requests across them, which means a single administrator credential can front OpenAI organization keys, Anthropic workspace keys, and cloud provider credentials all at once. When that admin credential is a value printed in public documentation, the concentration works against the defender.

The CyberSignal has tracked this pattern across the AI stack for months. Earlier this year, a SQL injection flaw in LiteLLM (CVE-2026-42208) was exploited within 36 hours of disclosure, and the reason it mattered was the same one that makes the default-key finding serious: the gateway’s database holds the provider keys for an entire organization. We saw the identical logic when an SSRF in the LMDeploy inference toolkit was used to reach cloud metadata within 12 hours. Different bug classes, same lesson: AI infrastructure sits close to high-value credentials and rich network access, so any weak point in it pays out quickly.

The default-key case is arguably the plainest version of the problem, because it needs no exploit at all. It is a credential that was never changed. For teams building a durable program around this, our complete guide to AI security lays out where gateway and application-layer controls fit alongside data, model, and monitoring defenses. Treating the AI gateway as a first-class production asset, with secrets management on par with the rest of your infrastructure, is what keeps a copy-paste placeholder from becoming an administrator login.

● Gateway Key Hygiene

One example key decides whether an exposed gateway answers a stranger.

Default Key Left In Place

The setup-guide example key (sk-1234) is never rotated. It still works as the administrator credential, so the gateway answers anyone who presents it. Wiz found nearly 1 in 10 exposed gateways in this state.

↓

Default Key Removed And Rotated

The example key is deleted and a unique master secret is set. The same request that worked a moment ago is now rejected, and access is logged to a real owner. This is the state every operator should confirm.

Source: Wiz Research, reported by The Hacker News, September 2026.

What LiteLLM Operators Should Verify (Rotate Admin Keys Immediately)

The response to this finding is a short list of checks, and none of them require waiting for a release. Work through them in order.

Confirm the default key is dead. Verify that sk-1234, and any other example or placeholder value, no longer authenticates against your gateway. Set a unique, high-entropy master secret (the LITELLM_MASTER_KEY in your configuration) if you have not already.
Rotate the admin credential and anything minted under it. Rotate the master key and any virtual keys that were issued while a default admin key was reachable. A rotation you cannot prove happened should be redone.
Remove default example keys everywhere they hide. Check running configuration, environment files, container images, Helm values, and infrastructure-as-code templates. A placeholder scrubbed from one file but baked into an image will come back on the next deploy.
Audit gateway logs. Review access logs for any authentication using the example key or the admin credential, and for administrative actions you cannot attribute to a known operator.
Reduce exposure. Keep the admin API off the open internet. Put the gateway behind network controls and authentication so that even a weak credential is not reachable by an anonymous request.
Rotate downstream provider keys if warranted. If a default admin credential was ever live on an exposed instance, treat the provider keys behind it as potentially reachable and rotate them (OpenAI, Anthropic, Bedrock, Azure, and the rest) as a precaution.

The single highest-value action is the first one. Remove the example key and rotate the administrator credential. Everything else hardens the deployment around that change.

Open Questions

Several details are not established in the reporting, and we are not filling them in. Wiz has not disclosed the total number of internet-facing LiteLLM gateways it scanned, so the nearly-10-percent figure is a rate without a published denominator. No affected organizations are named. And it is not confirmed whether LiteLLM has changed its setup guide to remove or replace the sk-1234 example. We will update this piece if the project or the researchers publish more.