This issue has been assessed as high severity. Review affected configurations immediately.
The threat model for cloud security has traditionally centred on data stores, compute resources, and credentials. Exposed S3 buckets, misconfigured IAM roles, and instance metadata service abuse are well-understood problems with established detection and remediation guidance. What changed in 2026 is that AI inference infrastructure joined that list of targets — not as a theoretical risk but as actively exploited attack surface.
Research published by Zenity Labs in June 2026 documented three distinct campaign types against exposed AI gateway infrastructure: autonomous offensive operations (using compromised LiteLLM servers to run AI-powered attack tools against third parties), compute theft (running large volumes of inference at the victim’s expense), and credential exfiltration (extracting API keys and configuration data from vulnerable server endpoints). The research identified hundreds of exploitation attempts against CVE-2026-40217 in LiteLLM, with exploitation beginning on the same day the patch was published.
The enabling condition for most of these attacks is a familiar cloud misconfiguration pattern: services that bind to all interfaces by default, deployed into cloud environments where network controls are looser than intended.
How These Services End Up Exposed
Ollama default binding. Ollama, the local LLM runtime, binds to 127.0.0.1 by default — intentionally localhost-only. The problem arises in cloud environments where developers set OLLAMA_HOST=0.0.0.0 to allow connections from other containers or services, without adequately restricting which external IPs can reach that port. A security group that allows inbound traffic on port 11434 from 0.0.0.0/0 is all it takes to expose an Ollama instance to the internet. Research in 2026 identified 175,000 such publicly exposed Ollama instances across 130 countries, the majority requiring no authentication.
LiteLLM exposed management port. LiteLLM, the open-source AI gateway proxy, listens on port 4000 by default. Deployed as a container in a cloud environment — whether directly on EC2/GCE/Azure VM or in a Kubernetes cluster with an exposed service — the combination of a misconfigured security group and the absence of authentication on the admin endpoint creates both a direct attack surface (for CVE-2026-40217 exploitation) and an unauthenticated admin interface.
Cloud environment networking assumptions. The root cause in many cases is that developers deploy AI infrastructure using the same approach they’d use for a localhost development service — and cloud networking does not enforce the same boundaries as localhost does. An EXPOSE 4000 in a Dockerfile plus a CloudFormation template with an open security group are sufficient to create an internet-facing admin panel that was intended to be internal-only.
ECS/GKE/AKS service exposure. Container orchestration environments can expose services in non-obvious ways. An internal LiteLLM service in a Kubernetes cluster becomes internet-accessible if a Load Balancer service type is used instead of ClusterIP, or if an ingress controller is misconfigured to route to it. These exposures are often discovered by cloud security teams long after the service was originally deployed.
CVE-2026-40217: The Vulnerability Enabling RCE
CVE-2026-40217 is a CVSS 8.8 remote code execution vulnerability in LiteLLM, discovered by X41 D-Sec. The flaw lies in the custom guardrail testing endpoint, which accepts user-controlled Python bytecode and executes it with insufficient sandboxing.
As a standalone vulnerability, CVE-2026-40217 requires existing authentication to exploit. But it is part of a four-CVE chain (rated CVSS 9.9 overall, discovered by Obsidian Security) that begins with privilege escalation from a default low-privilege user account to administrator via CVE-2026-47101 and CVE-2026-47102, then uses administrator access to trigger CVE-2026-40217 for code execution. An unauthenticated attacker with network access to a vulnerable LiteLLM instance can therefore achieve RCE through the full chain.
BerriAI shipped fixes across subsequent releases, with the complete fix set landing in LiteLLM v1.83.14-stable on 25 April 2026. Any LiteLLM instance running an earlier version is vulnerable to the full chain.
A separate vulnerability, CVE-2026-35029, affects LiteLLM’s admin endpoint and allows configuration data exfiltration — including API keys and internal routing information — without needing to escalate to the RCE stage.
Cloud Hardening: Security Group and Network Controls
The most important control is also the simplest: neither LiteLLM’s port 4000 nor Ollama’s port 11434 should be reachable from the internet.
AWS Security Groups. Security group rules should restrict inbound access on ports 4000 and 11434 to the specific source CIDR ranges that legitimately need access — internal VPC CIDR, specific management hosts, or an application load balancer security group.
# Deny pattern to avoid:
Inbound: TCP 4000 from 0.0.0.0/0
# Correct configuration:
Inbound: TCP 4000 from sg-0123456789abcdef0 (application tier SG only)
Inbound: TCP 4000 from 10.0.0.0/8 (internal VPC CIDR)For Ollama:
# Remove any rule allowing:
Inbound: TCP 11434 from 0.0.0.0/0
# Replace with:
Inbound: TCP 11434 from sg-<internal-services-sg> (only services that need model access)Azure Network Security Groups. NSG rules follow the same principle — restrict inbound traffic on 4000 and 11434 to the virtual network CIDR or specific subnet source prefixes. Use Application Security Groups to group the consumer services and reference them as the source.
GCP Firewall Rules. GCP’s default VPC firewall denies all inbound traffic unless explicitly allowed. If you have an allow rule covering the AI inference ports from external sources, remove it. Use service account-based firewall rules to limit access to the consumers.
Kubernetes Network Policies. For AI services running in Kubernetes, enforce a NetworkPolicy that restricts ingress to the inference service’s port to only the namespaces and pod selectors that legitimately need access:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: litellm-ingress-restriction
spec:
podSelector:
matchLabels:
app: litellm
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
litellm-consumer: "true"
ports:
- port: 4000Authentication and Access Controls
Network-level controls are the primary defence, but defence in depth requires authentication even for internal services — because internal network access is achievable through SSRF, lateral movement, or compromised internal systems.
LiteLLM master key. LiteLLM supports a LITELLM_MASTER_KEY environment variable that enforces API key authentication on all endpoints. Set this in production deployments. Without it, the admin interface and proxy endpoints are unauthenticated.
Virtual key management. Use LiteLLM’s virtual key system to issue per-service or per-user keys rather than sharing a single master key across all consumers. Virtual keys support rate limits, spend limits, and model access restrictions — reducing blast radius if a key is compromised.
Restrict admin endpoint access. LiteLLM’s /management API endpoints should be accessible only from specific, known management hosts. Implement a reverse proxy (nginx, Caddy, or an API gateway) that enforces source IP restrictions on admin paths before forwarding to LiteLLM.
Ollama authentication. Ollama does not natively support API key authentication in its standard deployment. The correct approach is to place it behind a reverse proxy that enforces authentication, or to restrict access entirely to network-level controls with no application-layer authentication assumed.
Patching and Configuration Audit
Update LiteLLM. Run v1.83.14-stable or any later release. Verify with litellm --version or by checking the installed package version. The full four-CVE chain is not fixed in any earlier version.
Rotate credentials stored in LiteLLM configuration. If you cannot confirm your LiteLLM instance was patched before exploitation of CVE-2026-40217 began in April 2026, treat all API keys stored in its configuration as compromised. This includes: OpenAI, Anthropic, Google, AWS Bedrock, and Azure OpenAI API keys, along with any database connection strings or webhook credentials.
Audit your AI service inventory. Cloud environments accumulate services over time. Run a scan of your cloud accounts for Ollama (11434) and LiteLLM (4000) across all regions and all compute types (EC2, ECS tasks, Kubernetes services, Azure Container Instances, Cloud Run). Include development and staging environments — these are often less carefully secured than production but run with credentials that have broader access.
# AWS: find security groups allowing inbound 11434 or 4000 from any source
aws ec2 describe-security-groups \
--filters "Name=ip-permission.from-port,Values=11434,4000" \
--query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]].{GroupId:GroupId,GroupName:GroupName}'Monitoring for Compromise
Anomalous inference usage. Unexpected spikes in API usage, calls to models outside normal operational patterns, or requests from source IPs outside the known consumer set are indicators of compute theft or credential compromise. Most commercial AI providers (Anthropic, OpenAI, Azure OpenAI) provide usage dashboards and spend alerts — configure threshold alerts.
LiteLLM audit logs. LiteLLM logs all requests. Monitor for requests to the /management API endpoints from unexpected sources, changes to model configuration, and new virtual key creation.
Outbound data transfer. A compromised LiteLLM server sending configuration data or making unexpected outbound connections to non-AI-provider destinations is a potential indicator of CVE-2026-35029 exfiltration activity.
The pattern underlying all of these attacks is consistent with other cloud infrastructure exposure problems: services designed for internal use, exposed to broader networks through misconfiguration, exploited systematically once discovered. The AI gateway layer is now part of the attack surface that cloud security teams need to account for alongside the traditional database, compute, and IAM targets.