In June 2026, Zenity Labs published research documenting how attackers are treating exposed AI infrastructure as a free compute platform and as a pivot point for attacking third parties. The most operationally significant finding was not the vulnerability exploitation or the credential theft — both of which were serious — but a specific observed incident in which an attacker used a victim organisation’s compromised LiteLLM server to run an AI-powered autonomous penetration testing tool against an unidentified French auction house.
The victim organisation in that case was not attacked. It was weaponised against someone else. The legal, reputational, and regulatory exposure of being the source of an attack — rather than a target — is a materially different risk profile that most AI governance frameworks have not yet considered.
What’s Actually Happening
Two categories of AI infrastructure are being systematically targeted:
LiteLLM deployments. LiteLLM is an open-source proxy that routes API calls across multiple LLM providers. Enterprise deployments route traffic to commercial APIs (OpenAI, Anthropic, Azure OpenAI, Google Gemini) with the organisation’s API credentials stored in the server configuration. An attacker who compromises a LiteLLM server gets: free access to those AI models (at the victim’s expense), the stored API credentials (reusable for other purposes), and in some cases access to internal routing and system prompt configuration that reveals the organisation’s AI application architecture.
Ollama endpoints. Ollama runs local open-source models (Llama, Mistral, Gemma variants). By default it binds to localhost; in cloud environments, misconfigured networking exposes port 11434 to the internet. At least 175,000 such servers were publicly exposed across 130 countries as of early 2026 — almost all requiring no authentication.
The exploitation of CVE-2026-40217, a remote code execution vulnerability in LiteLLM, began on the same day the patch was published. This is now a consistent pattern across high-value server software: same-day exploitation means controlled rollout is not a viable option. Unpatched is exposed.
The Three Risk Scenarios
Scenario 1: Compute theft and financial exposure. Enterprise LiteLLM deployments route to commercial API providers with per-token pricing. An attacker running large inference workloads through a compromised gateway runs up costs against the victim’s billing account. Depending on the models used and the volume, costs can reach tens of thousands of dollars before anomalous usage is detected. This is a direct financial loss, not a data loss event — and may not be covered by cyber insurance policies that focus on data breach.
Scenario 2: Credential and API key exfiltration. API keys stored in LiteLLM configuration are accessible via CVE-2026-35029 (an admin endpoint information disclosure vulnerability) without needing to escalate to RCE. Extracted credentials have independent value: AI API keys can be resold on dark web markets, used to run inference at scale for other operations, or leveraged to access other services using the same credentials. A compromised Anthropic API key, for instance, provides access to Claude across all organisational contexts that key covers.
Scenario 3: Weaponisation and third-party liability. The documented case of a victim’s LiteLLM server being used to attack a third party is the most novel risk vector. If your AI infrastructure is used to attack another organisation, the legal exposure — particularly in jurisdictions where computer misuse liability for negligent security controls exists — is genuinely uncertain and potentially significant. The NCSC’s guidance on third-party cyber risk has historically focused on supply chain compromise; the reverse (your systems being used as a weapon against others) is underexplored in most governance frameworks.
Assessing Your Exposure
CISOs should answer the following questions about their organisation’s AI infrastructure:
What AI gateway and inference infrastructure do we run? LiteLLM, Ollama, LocalAI, vLLM, and similar tools are frequently deployed by development teams without formal security review. The answer to this question is often “we don’t know” because these deployments happen outside the traditional application deployment pipeline.
What ports are internet-reachable? Scan for LiteLLM (4000), Ollama (11434), and common alternatives across all cloud accounts and regions, including development and staging environments. These scans should be part of regular external attack surface monitoring, not a one-time exercise.
Are API credentials stored in AI gateway configuration? LiteLLM’s configuration file typically contains API keys for every provider it routes to. These credentials need to be managed with the same discipline as other privileged credentials — rotated on schedule, monitored for anomalous usage, and revocable independently.
Are we on a patched version? LiteLLM v1.83.14-stable (released 25 April 2026) contains the complete fix for the four-CVE chain. Any earlier version is vulnerable to the full chain including RCE.
Governance Steps
Add AI inference infrastructure to your asset inventory. AI gateways and inference endpoints are not always captured by standard asset discovery tools. Add explicit discovery for the ports and process signatures associated with LiteLLM, Ollama, vLLM, and similar tools to your network scanning schedule.
Classify AI API keys as privileged credentials. API keys for commercial AI providers should be managed through your PAM solution or secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) rather than stored as plaintext in configuration files. Rotation schedules, usage monitoring, and emergency revocation procedures should mirror those for other privileged credentials.
Establish AI infrastructure change management. Development teams deploying AI gateways should follow the same change management process as any other internet-facing infrastructure. This is a culture and process problem as much as a technical one — AI tools move fast and teams want to experiment, but “spin up LiteLLM in dev and point it at prod credentials” is a risk pattern that keeps recurring.
Set up spend alerting on commercial AI API accounts. Most commercial AI providers offer spending limits and anomalous usage alerts. Configure these for all API accounts. An unexpected spike in inference volume — particularly for models outside normal operational use — is an early indicator of compute theft.
Define an AI incident response procedure. Standard IR runbooks cover data exfiltration, ransomware, and BEC. They typically do not address the AI-specific scenarios: how do you respond to compute theft? What do you do if your AI infrastructure has been used to attack a third party? Define the procedures, identify the stakeholders (legal, communications, the affected third party), and document the evidence preservation steps specific to AI gateway logs.
The Speed Problem
The exploitation of LiteLLM CVEs on the same day patches are published is significant. It means the traditional “patch within 30 days” policy framework is not an adequate response posture for AI infrastructure that is internet-accessible. The effective requirement is: patch within hours of publication for any internet-facing service with a known critical or high vulnerability.
This is achievable for managed cloud services where updates are automated. For self-hosted LiteLLM deployments, it requires an automated update pipeline (container image updates triggered by new image releases, for instance) rather than manual patching processes.
Organisations that cannot achieve near-real-time patching for internet-facing AI infrastructure should compensate with network-level controls: these services should not be reachable from the internet at all, behind a VPN or bastion host requirement.
The AI infrastructure attack surface is new enough that most organisations have not yet integrated it into their risk management processes. The research published in 2026 shows that attackers have. Closing that gap is the immediate priority.