Thousands of LiteLLM instances exposed: 1 in 10 uses default password
Exposed LiteLLM servers could let hackers drain AI budget, seize root access, and steal cloud credentials.

Image by Cybernews.
- Wiz found 294 LiteLLM servers that accept no login or the default master key.
- Exposed servers can leak AI provider tokens, prompts, responses, and connected internal tools.
- Attackers could run API calls on victims’ bills or use LiteLLM to reach deeper systems.
- Wiz says organizations should treat AI gateways as critical security assets, not simple development tools.
Key Takeaways by nexos.ai, reviewed by Cybernews staff.
Thousands of LiteLLM servers – centralized gateways to access different LLM providers – have been exposed online. Hundreds accept default passwords or require no authentication at all, allowing hackers to simply grab sensitive tokens and even hijack infrastructure by exploiting known vulnerabilities.
LiteLLM is an open-source AI gateway that lets users access multiple LLM providers, such as OpenAI, Anthropic, and Gemini, at once.
This self-hosted tool is hugely popular and, earlier this year, became the epicenter of a massive supply chain attack when attackers injected malware into the PyPI package downloaded millions of times every day. Its Docker container has been pulled over 240 million times.
Wiz, a Google-owned cybersecurity firm, scanned the internet and found thousands of exposed LiteLLM servers. Then it checked 3,074 of them and found 294 instances – roughly 1 in 10 – that require no authentication at all or accept the default master key “sk-1234.”
That’s a huge security oversight regardless of whether the server sits behind a firewall or is exposed to the open internet.
Wiz’s August scan revealed over 85,000 LiteLLM instances, most of which appeared to be test deployments or honeypots. More broadly, Wiz found that a third of cloud environments run a LiteLLM deployment, and many more instances aren’t easily accessible because they sit behind VPNs or firewalls.
Stay updated with our latest stories and follow us on social media
Be the first to discover new stories, ideas, and updates from our team.
The immediate danger is someone using your AI credentials to run API calls on your bill.
“Organizations route their LLM traffic through it so they can centrally manage their API keys, enforce budgets, apply guardrails, monitor usage, etc.,” Wiz explained in research, which was also presented at DEF CON 34.
Not only are the API keys exposed, but so are every prompt and response that flows through the LiteLLM instance, as well as external tools connected via MCP (Model Context Protocol).
While running up costs is a proven risk, attackers can use LiteLLM as a stepping stone to gain further access, because it also touches code execution – it runs server-side Python on every inference request and can route requests to arbitrary internal URLs.
Wiz pointed out that when LiteLLM has no authentication configured, all users are granted admin access.
Check if your data has been leaked
The researchers disclosed several other attack paths that are readily available for attackers.
Post-authorization root-level code execution is possible in unpatched versions of LiteLLM vulnerable to a bug tracked as CVE-2026-59821.
Separately, a broken authentication check on LiteLLM’s MCP endpoint allows attackers to log in without valid credentials, granting access to connected MCP tools (CVE-2026-59822).
Having access to the full MCP protocol, an attacker can read operations and execute tools with arbitrary arguments.
“If an MCP server exposes a database query tool, the attacker can run queries. Similarly, if it connects to GitHub, the attacker can read repositories and create issues. If it has access to a file system, the attacker can read and write files,” the report reads.
The researchers warn that AI gateways often hold credentials for every AI provider, execute arbitrary commands, connect to broader internal infrastructure, and operate with broad cloud permissions, yet are often secured with a single shared secret.
Wiz urges treating such systems as Tier-1 security assets rather than development tools.