# The Hidden Risks of AI Gateway Defaults: How a Single Test Key Exposed Thousands of Systems
An analysis of internet-facing AI gateway deployments found that a striking number of servers still accept the placeholder administrator key shown in the software’s official setup documentation. This single credential, left unchanged by operators, grants access to every API key, conversation log, and cloud credential stored or accessible by the gateway.
AI gateways sit between an organization’s applications and the external model providers they depend on. Because they route traffic and store credentials for multiple model services, they concentrate significant power in one piece of software — and that power becomes dangerous when default configurations are never replaced.
## The Scale of Exposure
A scan conducted in February identified over 3,000 LiteLLM gateways reachable on the public internet. Roughly ten percent of those accepted the sample admin key from the documentation. In nearly two hundred of those cases, no authentication key had been configured at all, meaning the server would accept any value presented to it. A second scan months later identified a much larger count, but many of those instances appear to be intentionally deployed as honeypots or test environments, making the numbers incomparable.
The documentation itself still carries the placeholder key, accompanied only by a comment instructing operators to swap it out with a random value before production use.
## Why a Single Default Key Unlocks So Much
The master key serves two purposes simultaneously: it authenticates administrative access and it enables authentication enforcement for the entire gateway. Before a certain software version, launching a gateway without a master key gave every incoming request full administrative rights automatically.
An administrator with access to the gateway can reach several sensitive resources:
– **Provider API keys** stored within the gateway for routing requests to external AI services.
– **Every prompt and response** passing through the gateway, which may contain proprietary data, credentials, or personal information.
– **Cloud infrastructure credentials** of the machine hosting the gateway, obtained through a metadata service endpoint.
– **Internal tools** connected via the Model Context Protocol (MCP), which can extend the gateway’s reach into an organization’s broader tool ecosystem.
Leaving provider keys exposed enables a known abuse pattern where attackers run model workloads on the victim’s account, generating costs and consuming resources without authorization.
## Reaching Cloud Credentials Through Built-In Features
The gateway software supports pass-through endpoints — routes that forward incoming requests to any URL an administrator specifies. Critically, the software does not validate whether the target URL points to a private address, localhost, or a cloud metadata endpoint. This means an administrator can configure a route that reaches the instance metadata service and retrieves the IAM credentials the cloud provider assigns to that machine.
Even cloud providers’ newer metadata authentication protocols do not prevent this, because the gateway forwards specific HTTP headers from the original request to the target destination, stripping a prefix before passing them along. This behavior allows the required authentication headers to reach the metadata service intact.
The software vendor’s published security policy categorizes attacks that depend on misconfigured setup — such as failing to set a master key — as issues outside its scope, treating them as operator errors rather than vulnerabilities. There is no assigned CVE and no planned fix for this path.
## Code Execution Flaws and Disputed Severity
The most severe code execution vulnerability identified in recent disclosures allows arbitrary code to run inside the gateway container. Before a specific stable release, endpoints used to create and update custom code guardrails skipped the sandbox and validation checks applied to other endpoints, meaning submitted Python code would execute directly inside the container.
When a deployment had no master key configured, every caller was treated as an administrator, giving them access to those endpoints without any privilege check. The vendor rates this issue as low severity, noting that it requires an already-authenticated high-privilege account. Security researchers argue the severity is higher given how commonly default or missing keys are found in the wild.
A separate vulnerability disclosed earlier in the year describes a sandbox escape technique using bytecode manipulation. The code execution process in the default container image runs with root-level permissions, meaning escaped code inherits those privileges. This flaw affected a broad range of versions before a specific release patched it.
## Other Active Threats Targeting the Same Software
Several older vulnerabilities in the same gateway software are already being exploited in real attacks:
– A vulnerability allowing unauthenticated attackers to open a valid Model Context Protocol session using any token — even a single character — was added to a federal government known-exploited vulnerability catalog. Scans show attackers probing endpoints with single-character tokens to discover which model services are reachable.
– A separate flaw allowing authenticated users to execute host-level commands through MCP test endpoints was chained with a host-header vulnerability to achieve the same result without any credentials at all. Recorded attacks using this chain involved installing cryptocurrency mining software.
– In one documented case, attackers gained access through an exposed gateway, extracted the master key, provider keys, and database connection string from the process environment, and then used the database credentials to copy records from the system’s model and virtual-key tables.
## Recommended Actions
The following steps address the vulnerabilities and misconfigurations described above:
1. **Replace the default administrator key** with a long, randomly generated value immediately. This change requires no software upgrade. Before rotating, verify whether a separate salt key is also configured, as the rotation procedure differs and using the wrong method can make stored credentials permanently unreadable.
2. **Upgrade to the latest stable release** of the software, which includes fixes for all documented vulnerabilities.
3. **If upgrading is not yet possible**, block access to MCP-related endpoints and the custom code guardrail testing endpoints at the reverse proxy or API gateway level.
4. **Restrict guardrail management endpoints** to administrators only and limit the creation of pass-through routes.
5. **Audit all pass-through endpoints** currently configured on the gateway, restrict the container’s outbound network traffic, and assign the narrowest possible cloud IAM role to the host workload.
6. **If unauthorized access is suspected**, audit the guardrails configuration for unfamiliar entries, restart the gateway process to clear any code held in memory, and rotate the provider keys, master key, and database credentials. Note that upgrading the software does not remove guardrails or SSH keys that an attacker may have registered during a prior compromise.
## Frequently Asked Questions
**What is an AI gateway?**
An AI gateway is software that sits between an organization’s applications and the external AI model providers it uses. It handles routing, authentication, billing, and sometimes prompt transformation or content filtering. Because it holds credentials for multiple model services, it becomes a high-value target.
**Why is a placeholder admin key so dangerous?**
Because the placeholder key doubles as both the admin credential and the mechanism that turns on authentication. If it is left unchanged, anyone who discovers it gains full control over the gateway and everything it can access.
**Can changing the default key fix everything?**
Changing the key requires no software upgrade and closes every attack path that depends on holding the default credential. However, it does not address underlying code vulnerabilities in older software versions, so upgrading is still necessary.
**What is LLMjacking?**
LLMjacking is the practice of using stolen AI model API keys to run inference workloads on someone else’s cloud account, generating unauthorized charges and consuming their allocated resources.
**Is there a fix for the metadata credential exposure path?**
No. The software vendor does not consider the pass-through feature a vulnerability, so there is no patch. The only mitigations are restricting outbound network access from the gateway container and applying the principle of least privilege to the cloud IAM role assigned to the host machine.
**How do I know if my gateway is misconfigured?**
Checking whether MCP routes or pass-through endpoints are enabled on a gateway you did not configure yourself is not straightforward. Standard vulnerability scanning approaches focus on detecting exploitation rather than identifying insecure configuration.
## Conclusion
AI gateways occupy a uniquely powerful position in modern application infrastructure. They hold the keys to multiple model providers, record every interaction that passes through them, and often run with broad cloud permissions. When default credentials are left in place, that concentration of access becomes an open invitation to attackers.
The vulnerabilities discussed here range from simple configuration oversights — leaving a placeholder key unchanged — to complex code execution flaws that reward the same lax setup. Organizations running these gateways must treat them as Tier-0 assets, rotate default credentials immediately, restrict network and IAM permissions tightly, and keep software updated to the latest patched versions.
A single overlooked setting can expose not just the gateway itself but the cloud account it runs on, the data flowing through it, and the internal tools connected to it. The fixes are known, the upgrades are available, and the time to act is now.
Thank you for reading
