Wiz Research has published the results of a scan covering 3,074 internet-exposed LiteLLM instances the open-source AI gateway middleware that organizations use to route requests between applications and model providers including OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, and Google Gemini. Of those instances, 294 accepted "sk-1234", the default master key shipped with every LiteLLM installation. An additional 191 instances had no authentication configured at all. Combined, 15.8% of scanned LiteLLM deployments offered full API access to any researcher or attacker who sent a single request.
What full API access to a LiteLLM instance provides is not access to the LiteLLM application itself. It provides access to everything LiteLLM is configured to relay to: every model provider API key stored in the instance configuration OpenAI keys, Anthropic keys, Azure credentials, AWS access keys, Google Cloud service account tokens and, in many enterprise deployments, the cloud IAM credentials used to authenticate LiteLLM to managed AI services. Microsoft has separately documented active exploitation of exposed LiteLLM instances in the wild, with threat actors using harvested credentials to access model APIs for their own purposes and to move laterally into the cloud accounts of victim organizations.
For technology organizations, financial institutions, government agencies, and enterprises across Lebanon, the UAE, Saudi Arabia, and Nigeria that have deployed LiteLLM or similar AI gateway middleware to centralize model access in production, this research describes an active credential exposure risk one that is invisible to traditional endpoint and network monitoring because the attack surface is the AI middleware layer, not the application or perimeter.
LiteLLM is an open-source proxy that sits between an organization's applications and multiple AI model providers, translating between provider APIs, managing rate limits, routing requests, logging usage, and applying access controls through a unified interface. Organizations deploy it to avoid building separate integrations for each AI provider, to control which models different applications can access, and to centralize billing and usage tracking for AI across the enterprise.
Because LiteLLM sits at the center of an organization's AI model access architecture, organizations should treat it and similar ai gateways as Tier-1 security assets, since their configuration contains the complete set of credentials used to authenticate to model providers. A single LiteLLM configuration file can hold API keys for ten different providers, AWS access keys with permissions to AWS Bedrock, Azure service principal credentials, and Google Cloud service account tokens. Every credential the organization has provisioned for AI model access passes through or is stored by the LiteLLM instance.
A cybersecurity risk assessment identifies, evaluates, and prioritizes potential threats and vulnerabilities around these systems. Regular risk assessments are foundational to modern cybersecurity and corporate governance because they help organizations understand their most important risks and the appropriate actions to take.
LiteLLM ships with "sk-1234" as the default master key for its proxy API. The master key provides administrative access to the LiteLLM configuration including the ability to read all stored credentials, create new virtual API keys, modify routing policies, and access the full request and response logs for every AI interaction routed through the proxy. An organization that deploys LiteLLM without changing this default key has effectively published administrative access to their AI infrastructure on the internet.
Wiz's scan methodology was straightforward: send a single authenticated request to every internet-exposed LiteLLM instance using the "sk-1234" master key and observe the response. In a cybersecurity risk assessment, that kind of validation maps directly to typical steps such as asset identification, threat analysis, and risk prioritization. Of 3,074 instances scanned:
On every accessible instance, Wiz documented what was available: a complete inventory of configured model providers and their API keys, the virtual key management interface for creating additional access credentials, the spend tracking and usage logs showing which applications were sending which prompts, and in many enterprise deployments, credentials, critical data, software, and systems exposed through LiteLLM, including cloud providers such as AWS access keys and Azure service principal IDs with permissions to managed AI services across cloud environments.
This kind of threat and vulnerability analysis pinpoints weaknesses, while risk evaluation weighs likelihood and severity to determine the level of risk.
Microsoft's threat intelligence team has separately confirmed active exploitation of exposed LiteLLM instances consistent with these findings with threat actors using harvested model provider API keys for their own model access and using cloud IAM credentials to access the broader cloud account of the victim organization. These findings help organizations prioritize resource allocation for cybersecurity and build actionable remediation plans for identified vulnerabilities.
Technology organizations across the UAE and Saudi Arabia deploying LiteLLM to power internal AI tooling, customer-facing AI features, and the ai workloads behind those deployments or AI-assisted workflows represent the highest-density deployment profile for this risk. DevOps teams often deploy LiteLLM rapidly as an internal tool without the security review that customer-facing applications receive and the default credential is never changed because changing it is an optional configuration step, not a required one. UAE cybersecurity frameworks and Saudi NCA ECC both require that production systems maintain access controls proportionate to the data they handle: a system with administrative access to all cloud AI credentials is unambiguously a high-sensitivity system. Regular risk assessments are also required under frameworks and regulations such as GDPR, HIPAA, and ISO 27001 when personal data or other sensitive processing is involved. GDPR requires organizations to protect personal data, non-compliance can lead to penalties, and ISO 27001 provides a framework for information security management that can also strengthen customer trust in security practices.
Lebanese banks and Nigerian financial institutions experimenting with AI in customer-facing and internal workflows often use middleware like LiteLLM to centralize model access across multiple internal projects. A compromised LiteLLM instance in a financial institution does not just expose AI model API keys it exposes the cloud IAM credentials used to authenticate to cloud-hosted AI services, which frequently have broader permissions than the AI use case requires. CBUAE and CBN cybersecurity frameworks require that financial institutions apply appropriate access controls to systems handling sensitive credentials, and that those controls be audited and verified rather than assumed. In practice, this is where a cybersecurity risk assessment strengthens incident preparedness and response capabilities by validating how those controls hold up under realistic failure scenarios. In financial environments, stronger compliance practices also help prevent costly data breaches by reducing control gaps before attackers can exploit them.
Government agencies and research institutions across the MENA region that have deployed AI infrastructure for pilot projects or internal automation frequently do so on compressed timelines, with security review treated as a follow-on step. LiteLLM instances deployed for a pilot that transitions to production use retain their pilot-era configuration including default credentials that were acceptable for a closed test environment but represent an open API door in a production deployment reachable from the internet. LiteLLM is now common across cloud environments and broader research found it present in approximately one-third of them. More than 85,000 LiteLLM instances were scanned in August 2026, showing the scale of exposure discovery. For federal civilian agencies, this matters even more because CISA added CVE-2026-42271 to the KEV catalog on June 8, 2026, and its CVSS score is 8.7, indicating high severity. Other serious LiteLLM issues include CVE-2026-48710, which allows unauthenticated RCE with a CVSS score of 10.0, and CVE-2026-59822, which allows attackers to log in without valid credentials.
The Wiz scan was conducted by security researchers disclosing responsibly. Active attackers conducting the same scan do not disclose they harvest credentials and use them silently. An organization that fixes its LiteLLM configuration after reading this disclosure has closed the door forward. It has not been answered whether its credentials were already harvested during the period the instance was exposed.
SHELT's REVA threat intelligence service monitors the sources where harvested AI infrastructure credentials appear after compromise:
Changing the master key prevents future access using the default credential. It does not address the possibility that the credential was used during the period the instance was exposed. The key rotation steps above are required: every API key and cloud credential stored in the LiteLLM configuration should be treated as compromised if the instance was accessible with the default key. The cost of credential rotation is significantly lower than the cost of an AI model API abuse incident or a cloud account breach.
If your LiteLLM instance is not internet-accessible and is only reachable from within your VPN-connected network, the internet scanning risk described by Wiz does not apply to your external exposure. However, the credential storage risk remains: any attacker who achieves access to your internal network through another vector phishing, RMM tool abuse, VPN credential theft can reach your LiteLLM instance and harvest its stored credentials. Internal-only does not mean the credentials it stores are safe from an insider threat or a network-lateral attacker.
Yes. A REVA engagement includes a search of dark web markets and criminal market sources for any evidence that your organization's model provider API keys, cloud IAM credentials, or AI infrastructure access has appeared in credential markets or criminal infrastructure. Given the active exploitation documented by Microsoft, organizations in technology, financial services, and government sectors with AI middleware deployments should treat this as an immediate intelligence question rather than a theoretical one. This kind of dark web monitoring also supports regulatory compliance by providing audit evidence of active threat detection and response for regulators and internal reviews.
.png)
© SHELT 2023 Privacy Policy | Terms & Conditions
.png){kind=small}
