Nearly 10% of Exposed LiteLLM Gateways Still Accepted the Default Admin Key

The finding comes from security researchers at Wiz, who scanned 3,074 internet-facing LiteLLM instances and found that 294 deployments, or 9.6%, accepted the default master key sk-1234 or had no authentication configured. Of those, 191 instances had no authentication at all.

The issue is particularly concerning because the LiteLLM master key is not simply an API credential. It functions as the proxy's administrative credential and is also used as the secret for signing session JWTs.

An attacker who knows the unchanged example key may therefore gain significantly more access than simply being able to send AI requests.

What Is LiteLLM?

LiteLLM is an open-source gateway designed to provide a unified interface for interacting with multiple large language model providers.

Organizations can use it to route requests between different AI services while managing:

• API keys
• Model access
• Usage limits
• Budgets
• Authentication
• AI request routing
• Provider integrations
• Virtual keys

The platform can sit between applications and AI providers such as OpenAI, Anthropic and other model services.

Because it can manage credentials and AI traffic centrally, a compromised LiteLLM deployment could expose sensitive information and provide attackers with access to downstream AI infrastructure.

LiteLLM's own documentation uses sk-1234 as an example master key in configuration and quick-start material.

Wiz Finds 294 Exposed Deployments

Wiz researchers scanned approximately 3,000 publicly accessible LiteLLM gateways in February 2026.

The scan identified:

Finding	Number
Internet-facing instances scanned	3,074
Accepted default sk-1234 or required no authentication	294
Percentage affected	9.6%
Instances with no authentication	191
Percentage with no authentication	6.2%

The researchers cautioned that these numbers represent systems visible through their scanning methodology and should not be interpreted as the total number of LiteLLM deployments worldwide.

A later scan in August reportedly identified more than 85,000 instances, although Wiz said many appeared to be honeypots or test environments.

The Problem With sk-1234

The security concern goes beyond the use of a weak password.

LiteLLM treats the master key as the administrative credential for the proxy.

If an administrator leaves the example value unchanged, anyone who knows the documented value can potentially authenticate to the exposed gateway.

The problem becomes even more serious because LiteLLM also uses the master key as an HS256 secret for signing session JWTs.

This means that an attacker who knows the master key may be able to forge authentication sessions for the proxy.

In effect, a value intended merely as a documentation example can become a gateway-level credential when deployed unchanged in a production environment.

Missing Authentication Creates Another Risk

Wiz found that 191 of the 294 affected instances had no authentication configured.

In such configurations, users can potentially reach administrative functionality without supplying a legitimate credential.

Researchers also found that unauthenticated deployments could assign users the PROXY_ADMIN role by default, creating another route to administrative capabilities.

LiteLLM has since changed this behavior, moving the default role away from administrative access and adding authorization checks to sensitive guardrail functionality.

From AI Gateway Exposure to Remote Code Execution

The default-key problem becomes significantly more dangerous when combined with vulnerable LiteLLM versions.

Wiz identified CVE-2026-59821, a vulnerability involving LiteLLM's custom code guardrails.

The flaw can allow authenticated attackers to achieve remote code execution on the host.

According to Wiz, deployments using the default master key and running an affected version before 1.82.0 could effectively expose the code-execution vulnerability without requiring a separately obtained credential.

A single request using the known default key could potentially lead to code execution inside the LiteLLM container and provide access to resources available to the container.

MCP Authentication Bypass

Wiz also identified another vulnerability tracked as CVE-2026-59822 involving LiteLLM's Model Context Protocol (MCP) endpoint.

The flaw allows an attacker to create a valid session using an arbitrary Bearer token.

Researchers reported finding the vulnerability exploitable across hundreds of internet-facing LiteLLM deployments.

The issue has since been addressed, and Wiz said it observed exploitation of the vulnerability through its honeypot infrastructure.

CVE-2026-59822 has also been added to the U.S. Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalog.

Attackers Could Move Beyond LLMjacking

A compromised AI gateway might initially appear most useful for LLMjacking, where attackers abuse someone else's AI accounts and computing resources.

However, Wiz's investigation demonstrates that the consequences can extend considerably further.

An attacker who gains administrative access may potentially target:

• AI provider API credentials
• Model configurations
• User sessions
• Internal applications
• Cloud resources
• Database credentials
• Environment variables
• Other systems reachable from the gateway

This changes the threat from simply generating unauthorized AI requests to potentially compromising an organization's broader cloud environment.

Cloud Credential Theft Risk

Wiz also identified a separate attack path involving LiteLLM's pass-through endpoint functionality.

The feature can allow requests to be forwarded to specified destinations.

Researchers found that insufficient URL validation could potentially allow an authenticated attacker to abuse this functionality to reach sensitive resources.

Depending on the environment, this could expose credentials or other information available from cloud services.

Wiz noted that this behavior was not classified as a vulnerability by the project and therefore did not receive a CVE. However, the researchers said it can become particularly dangerous when combined with default credentials or missing authentication.

LiteLLM Can Become a High-Value Target

AI gateways occupy a particularly sensitive position within modern infrastructure.

A single deployment may have access to multiple AI providers and contain credentials used to communicate with them.

For example, a compromised gateway could potentially expose:

• OpenAI API credentials
• Anthropic credentials
• Google AI credentials
• Database connection strings
• Cloud environment variables
• AI usage data
• User prompts
• Model configurations
• Internal application information

The gateway therefore represents an attractive target for attackers looking to move from AI infrastructure into the wider environment.

Public Exposure Makes the Problem Worse

Internet-facing AI infrastructure is particularly vulnerable because attackers can continuously scan the internet for exposed management interfaces.

Wiz's research shows that thousands of LiteLLM deployments can be discovered through internet-wide scanning.

An attacker does not necessarily need to know the organization operating the gateway beforehand.

Instead, they can:

1. Discover publicly exposed LiteLLM instances.
2. Identify the LiteLLM version.
3. Test authentication.
4. Attempt known default credentials.
5. Determine whether administrative functionality is exposed.
6. Exploit vulnerable features where applicable.
7. Search for credentials or cloud access.
8. Pivot into additional infrastructure.

This makes exposed AI gateways a potentially attractive entry point for automated attacks.

Security Recommendations

Organizations running LiteLLM should treat the gateway as a privileged infrastructure component rather than simply an AI proxy.

Replace Default Credentials

Immediately replace sk-1234 with a strong, randomly generated master key.

If the default key has ever been used in a publicly accessible deployment, organizations should treat it as compromised and rotate it.

Never Leave Administrative Interfaces Public

Administrative functionality should not be directly exposed to the internet unless there is a specific business requirement.

Organizations should consider:

• VPN access
• Private networking
• IP allowlisting
• Zero-trust access controls
• Reverse-proxy authentication
• Network segmentation

Upgrade LiteLLM

Organizations should upgrade to versions containing the relevant security fixes and review the project's security advisories for additional updates.

Wiz specifically identified fixes associated with the vulnerabilities discussed in its research.

Protect Provider Credentials

API keys for AI providers should not be unnecessarily exposed through gateway configuration.

Secrets should be stored using appropriate secrets-management systems rather than hard-coded into configuration files or container images.

Monitor AI Gateway Activity

Security teams should monitor for:

• Unexpected administrative logins
• Requests using default credentials
• Unusual API consumption
• New virtual keys
• Unexpected model configurations
• Changes to routing rules
• Unknown MCP sessions
• Suspicious outbound connections
• Access to cloud metadata services
• Unexpected changes to environment variables

If sk-1234 Was Used in Production

Organizations that previously operated an internet-accessible LiteLLM gateway with the default key should assume that the credential may have been exposed.

Recommended response steps include:

1. Replace the LiteLLM master key immediately.
2. Rotate all AI-provider API keys accessible to the gateway.
3. Terminate active sessions.
4. Upgrade LiteLLM to a patched version.
5. Restrict administrative endpoints.
6. Review authentication and access logs.
7. Search for unauthorized virtual keys.
8. Investigate unusual AI API consumption.
9. Review cloud credentials accessible from the gateway.
10. Check for signs of persistence or lateral movement.

Organizations should also investigate historical logs rather than assuming that changing the password alone resolves the incident.

The Documentation-to-Production Problem

The incident highlights a recurring security problem in software deployment: example credentials can become real credentials when administrators copy configuration examples directly into production.

A value such as sk-1234 is harmless when used purely as documentation.

It becomes a serious security weakness when:

• The service is publicly accessible.
• The example key is accepted as a real credential.
• The key provides administrative privileges.
• The gateway has access to sensitive downstream systems.

LiteLLM's documentation currently continues to show sk-1234 in example configurations, making it particularly important for administrators to understand that the value must be replaced before deployment.

Conclusion

Wiz's investigation shows how a simple configuration mistake can turn an AI gateway into a potentially powerful attack surface.

Nearly 10% of the 3,074 publicly accessible LiteLLM deployments examined by researchers either accepted the documented sk-1234 master key or had no authentication configured.

The risk extends beyond unauthorized AI usage. When combined with vulnerable LiteLLM versions and exposed administrative functionality, attackers could potentially progress from a known default credential to code execution, credential theft and broader cloud compromise.

As organizations increasingly deploy centralized AI gateways to manage multiple models and providers, these systems need to be treated as critical infrastructure.

Strong unique credentials, network isolation, timely patching, secrets management and continuous monitoring are essential to prevent an exposed AI gateway from becoming a stepping stone into the wider enterprise environment.