Back to Intelligence

CVE-2026-35029 and CVE-2026-59823: LiteLLM Gateway Defense, Detection, and Remediation Guide

SA
Security Arsenal Team
October 17, 2026
13 min read

LiteLLM sits in a dangerous place in enterprise AI architecture: it is the broker between internal applications and external model providers such as OpenAI and Anthropic. Reporting from Infosecurity Magazine warns that two high-risk vulnerabilities, CVE-2026-35029 and CVE-2026-59823, affect LiteLLM deployments used by enterprises to connect AI applications to those providers. The defensive issue is not only remote compromise of a Python service. It is the concentration of provider API keys, tenant routing logic, prompt and response telemetry, model allow-lists, and upstream trust relationships in one gateway.

The public summary available for this post does not include fixed-version numbers, CVSS vectors, or confirmed in-the-wild exploitation. Do not let that gap slow response. Treat internet-exposed or shared-tenant LiteLLM gateways as high-value assets until you have verified the vendor advisory, patched to a confirmed fixed release, rotated exposed credentials where warranted, and proven that egress is constrained to approved model providers.

Why LiteLLM is a blast-radius multiplier

LiteLLM is commonly deployed as a proxy/gateway that normalizes calls to multiple large language model providers. In practical terms, that means the service often holds or can reach:

  • Provider API keys for OpenAI, Anthropic, Azure OpenAI, and other backends.
  • Virtual keys issued to internal applications, teams, or customers.
  • Routing policy that decides which tenant or application can invoke which model.
  • Request and response logs that may contain prompts, retrieved context, source code, secrets, regulated data, or customer content.
  • Callbacks, spend-tracking webhooks, and administrative endpoints.
  • Network trust to upstream provider APIs and sometimes to internal tools such as vector databases, secret stores, Redis, Postgres, and observability pipelines.

A vulnerability in this layer can therefore become more than a single CVE. Depending on root cause and deployment posture, the worst-case outcomes include provider-key theft, unauthorized model use at your expense, cross-tenant data exposure, prompt/log leakage, malicious route changes, and persistence inside the AI control plane.

Technical analysis

Affected product and platforms

The affected product identified in the news item is LiteLLM, a widely used open-source LLM gateway/proxy. Enterprise deployments typically run on Linux containers, Kubernetes, virtual machines, or PaaS, fronted by uvicorn, gunicorn, hypercorn, or an equivalent ASGI/WSGI server, often behind nginx, Envoy, an ingress controller, or a cloud load balancer.

Because the source summary does not list vulnerable or fixed versions, do not guess from package age alone. Inventory every LiteLLM runtime, including sidecars and developer gateways, then verify against the authoritative sources:

CVE identifiers and severity

The identifiers to track are CVE-2026-35029 and CVE-2026-59823. The reporting characterizes them as high-risk. CVSS scores and vectors are not included in the provided summary, so defenders should pull the official CVSS and affected-version data from NVD, GitHub Security Advisories, and the LiteLLM release notes rather than relying on screenshots or reposts.

Operationally, prioritize any LiteLLM instance that is one or more of the following: reachable from the internet, reachable from less-trusted application networks, shared by multiple business units or customers, able to read provider keys from environment files or a secret store, permitted broad outbound egress, or running with an exposed administrative interface.

Defender view of the likely attack surface

Until the vendor technical write-up is reviewed, avoid assuming a specific memory-corruption or injection primitive. The defensible assumption is architectural: a gateway that terminates tenant requests, stores or retrieves powerful credentials, and fans out to third-party APIs must be treated as part of the identity and data perimeter.

Focus validation on these control points:

  • Authentication and authorization on proxy, admin, key-management, spend-management, and callback endpoints.
  • Tenant isolation for virtual keys, budgets, model permissions, and logging views.
  • Server-side request handling that could be abused to reach unintended internal or external destinations if route validation fails.
  • Secret handling in environment variables, mounted files, container specs, CI/CD variables, and logs.
  • Upstream TLS verification, provider endpoint allow-listing, and protection against credential leakage to attacker-controlled hosts.
  • Rate limits, model allow-lists, and budget guardrails that reduce financial abuse even if application-layer access is obtained.

Exploitation status

The provided news summary does not state a public proof of concept, confirmed active exploitation, or CISA Known Exploited Vulnerabilities listing. That is not evidence of safety; it is an intelligence gap. Check CISA KEV daily during triage: https://www.cisa.gov/known-exploited-vulnerabilities-catalog. If either CVE is added to KEV, move to emergency change and credential rotation under your exploited-vulnerability playbook.

Detection and response

The detections below are behavior-based because the public item does not provide stable indicators of compromise. They are tuned for LiteLLM gateway behavior rather than generic Python noise: unexpected shell execution from the gateway runtime, outbound connections from the gateway to non-provider destinations, and access to secret material followed by egress.

Before deploying, baseline which hosts and containers normally run LiteLLM, which service account owns the process, which parent process starts it, and which destinations are approved: api.openai.com, api.anthropic.com, your Azure OpenAI endpoints, and any explicitly approved providers. Alert logic should compare observed egress to that allow-list, not merely flag all AI traffic.

YAML
---
title: LiteLLM Gateway Runtime Spawning Shell or Downloader
id: 3d7f1b84-7e26-4b94-9a1d-cve202635029
status: experimental
description: Detects shell, downloader, or utility execution spawned by Python/ASGI processes associated with LiteLLM gateways. Useful for post-exploitation triage where exact CVE mechanics are not yet public.
references:
  - https://www.infosecurity-magazine.com/news/high-risk-vulnerabilities-llm-tool/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/06/06
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|contains:
      - 'python'
      - 'uvicorn'
      - 'gunicorn'
      - 'hypercorn'
      - 'litellm'
    ParentCommandLine|contains:
      - 'litellm'
      - 'uvicorn'
      - 'gunicorn'
      - 'hypercorn'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
  condition: selection_parent and selection_child
falsepositives:
  - Container health checks or package-manager hooks during controlled deploys
level: high
---
title: LiteLLM Process Reading Secret Material
id: 8c2a9e17-5bd4-4fd1-8e62-cve202659823
status: experimental
description: Detects LiteLLM gateway runtime opening common secret files or cloud metadata paths outside expected startup behavior.
references:
  - https://www.infosecurity-magazine.com/news/high-risk-vulnerabilities-llm-tool/
  - https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/06/06
tags:
  - attack.credential_access
  - attack.t1552
logsource:
  category: file_event
  product: linux
detection:
  selection_process:
    Image|contains:
      - 'python'
      - 'uvicorn'
      - 'gunicorn'
      - 'hypercorn'
      - 'litellm'
    CommandLine|contains:
      - 'litellm'
      - 'uvicorn'
      - 'gunicorn'
      - 'hypercorn'
  selection_target:
    TargetFilename|contains:
      - '/.env'
      - '/run/secrets/'
      - '/var/run/secrets/'
      - '/root/.aws/'
      - '/root/.config/'
      - '/etc/secrets/'
      - '/proc/1/environ'
  condition: selection_process and selection_target
falsepositives:
  - Startup reads from mounted Kubernetes secrets; suppress known init and readiness behavior by container image and namespace
level: high
---
title: LiteLLM Gateway Egress to Non-Allowlisted Destination
id: 51f6d3a9-b128-47c1-a7d0-litellmegress
status: experimental
description: Flags outbound connections from LiteLLM runtime processes to destinations outside an approved model-provider and telemetry allow-list.
references:
  - https://www.infosecurity-magazine.com/news/high-risk-vulnerabilities-llm-tool/
  - https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/06/06
tags:
  - attack.command_and_control
  - attack.exfiltration
  - attack.t1071
  - attack.t1041
logsource:
  category: network_connection
  product: linux
detection:
  selection_process:
    Image|contains:
      - 'python'
      - 'uvicorn'
      - 'gunicorn'
      - 'hypercorn'
      - 'litellm'
    CommandLine|contains:
      - 'litellm'
      - 'uvicorn'
      - 'gunicorn'
      - 'hypercorn'
  selection_bad_dest:
    DestinationHostname|contains:
      - '.onion'
      - 'pastebin'
      - 'webhook.site'
      - 'ngrok'
      - 'trycloudflare'
      - 'requestbin'
  filter_approved:
    DestinationHostname|contains:
      - 'api.openai.com'
      - 'api.anthropic.com'
      - 'openai.azure.com'
  condition: selection_process and selection_bad_dest and not filter_approved
falsepositives:
  - Approved callbacks, proxy telemetry, or additional providers; replace generic bad-destination list with environment-specific egress policy
level: medium
KQL — Microsoft Sentinel / Defender
// Hunt LiteLLM gateway processes with suspicious children, secret access strings, or rare egress.
// Tune ApprovedProviders and KnownGatewayHosts before production use.
let ApprovedProviders = dynamic(['api.openai.com','api.anthropic.com','openai.azure.com']);
let SuspiciousChildren = dynamic(['/bin/sh','/bin/bash','curl','wget','nc','ncat','python','base64']);
union isfuzzy=true
(
  DeviceProcessEvents
  | where TimeGenerated > ago(24h)
  | where InitiatingProcessFileName has_any ('python','uvicorn','gunicorn','hypercorn','litellm')
     or InitiatingProcessCommandLine has_any ('litellm','uvicorn','gunicorn','hypercorn')
  | where FileName has_any ('sh','bash','curl','wget','nc','ncat','python') or ProcessCommandLine has_any ('base64','/dev/tcp','Invoke-WebRequest')
  | project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName, ReportId
),
(
  Syslog
  | where TimeGenerated > ago(24h)
  | where ProcessName has_any ('python','uvicorn','gunicorn','hypercorn','litellm') or SyslogMessage has_any ('litellm')
  | where SyslogMessage has_any ('OPENAI_API_KEY','ANTHROPIC_API_KEY','/run/secrets','/var/run/secrets','.env','/dev/tcp','base64 -d','curl ','wget ')
  | project TimeGenerated, Computer, HostName, ProcessName, SyslogMessage, SeverityLevel
),
(
  DeviceNetworkEvents
  | where TimeGenerated > ago(24h)
  | where InitiatingProcessFileName has_any ('python','uvicorn','gunicorn','hypercorn','litellm')
     or InitiatingProcessCommandLine has_any ('litellm','uvicorn','gunicorn','hypercorn')
  | extend Dest = tostring(RemoteUrl)
  | where isnotempty(Dest) and not (Dest has_any (ApprovedProviders))
  | summarize Connections=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP, Dest, RemotePort
  | order by Connections desc
),
(
  CommonSecurityLog
  | where TimeGenerated > ago(24h)
  | where DeviceProduct has_any ('nginx','envoy','istio','ingress','apache','zscaler','palo','fortinet','checkpoint') or isnotempty(RequestURL)
  | where RequestURL has_any ('litellm','/key/generate','/key/update','/model/new','/config/update','/callbacks','/spend') or UriQuery has_any ('api_key','token','secret')
  | project TimeGenerated, SourceIP, DestinationIP, RequestURL, RequestMethod, HttpUserAgent, DeviceAction, DeviceProduct
)
VQL — Velociraptor
-- Velociraptor hunt: LiteLLM runtime, suspicious children, and live network connections
-- Run on Linux gateway hosts and container nodes where pslist/netstat are visible.
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)(python|uvicorn|gunicorn|hypercorn|litellm)'
   OR CommandLine =~ '(?i)(litellm|uvicorn|gunicorn|hypercorn)'

SELECT Pid, Name, LocalAddr, LocalPort, RemoteAddr, RemotePort, State
FROM netstat()
WHERE Name =~ '(?i)(python|uvicorn|gunicorn|hypercorn|litellm)'
   AND NOT (RemoteAddr =~ '(?i)(openai|anthropic|azure|127\.|::1)')

SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(base64|/dev/tcp|curl |wget |nc |ncat |sh -c|bash -c)'
   AND Ppid IN (SELECT Pid FROM pslist() WHERE CommandLine =~ '(?i)(litellm|uvicorn|gunicorn|hypercorn)')
Bash / Shell
#!/usr/bin/env bash
# LiteLLM CVE-2026-35029 / CVE-2026-59823 triage and hardening helper.
# This does NOT claim a fixed version. Set FIXED_VERSION from the official LiteLLM advisory before enforcing.
set -euo pipefail

FIXED_VERSION="${FIXED_VERSION:-}"
APPROVED_EGRESS="api.openai.com api.anthropic.com openai.azure.com"

if [[ -z "$FIXED_VERSION" ]]; then
  echo 'Set FIXED_VERSION to the vendor-confirmed patched release from LiteLLM advisories before enforcement.'
  echo 'Inventory and audit mode will still run.'
fi

echo '== Python/LiteLLM inventory =='
python3 -m pip show litellm 2>/dev/null || true
pip show litellm 2>/dev/null || true

echo '== Running gateway-like processes =='
ps -eo pid,ppid,user,comm,args | grep -Ei 'litellm|uvicorn|gunicorn|hypercorn' | grep -v grep || true

echo '== Listening sockets for gateway runtimes =='
ss -lntup 2>/dev/null | grep -Ei 'python|uvicorn|gunicorn|hypercorn|litellm' || true

echo '== Container images containing litellm =='
if command -v docker >/dev/null 2>&1; then docker ps --format '{{.ID}} {{.Image}} {{.Names}}' | grep -Ei 'litellm|llm|gateway' || true; fi
if command -v crictl >/dev/null 2>&1; then crictl ps 2>/dev/null | grep -Ei 'litellm|llm|gateway' || true; fi

echo '== Secret exposure audit: do not print values =='
env | grep -Ei 'OPENAI|ANTHROPIC|AZURE|API_KEY|TOKEN|SECRET' | sed -E 's/=.*/=REDACTED/' || true

if [[ -n "$FIXED_VERSION" ]]; then
  CURRENT="$(python3 -m pip show litellm 2>/dev/null | awk '/^Version:/ {print $2}' || true)"
  echo "Installed litellm: ${CURRENT:-unknown}; required fixed version: $FIXED_VERSION"
  if [[ -z "$CURRENT" ]]; then
    echo 'LiteLLM not installed via pip in this context; check containers and virtualenvs.'
  elif [[ "$CURRENT" != "$FIXED_VERSION" ]]; then
    echo 'ACTION REQUIRED: upgrade in a tested environment, for example: python3 -m pip install --upgrade litellm=='"$FIXED_VERSION"
  else
    echo 'Version matches FIXED_VERSION. Continue with key rotation and egress validation.'
  fi
fi

echo '== Egress self-test: expected failures indicate filtering =='
for host in $APPROVED_EGRESS; do
  timeout 5 bash -c "cat < /dev/null > /dev/tcp/$host/443" && echo "approved-ok:$host" || echo "approved-fail:$host"
done
for host in webhook.site requestbin.com example.invalid; do
  timeout 5 bash -c "cat < /dev/null > /dev/tcp/$host/443" && echo "unexpected-open:$host" || echo "blocked-or-unresolved:$host"
done

Immediate response priorities

  1. Inventory every LiteLLM instance. Search package manifests, container images, Helm charts, Terraform, Ansible, systemd units, Docker Compose files, and Kubernetes deployments. Include experimental and developer gateways, which are frequently outside vulnerability-management scope.
  2. Confirm exposure. Determine whether proxy and admin endpoints are internet-facing, reachable from user VLANs, reachable from CI/CD runners, or limited to a service mesh. A private gateway can still be high risk if it holds broad provider keys.
  3. Verify the advisory and patch to the exact fixed release. Because fixed versions are not present in the source summary, pin only after reading LiteLLM release notes and GitHub Security Advisories. Avoid blind latest upgrades in production if a breaking change could disrupt routing; stage, test provider failover, then deploy.
  4. Rotate credentials where exposure is plausible. Rotate OpenAI, Anthropic, Azure OpenAI, virtual keys, database passwords, Redis credentials, callback secrets, and any cloud role credentials accessible from the gateway if the host was exposed, unpatched, shared-tenant, or shows suspicious process or egress activity.
  5. Constrain egress. Default-deny outbound traffic from LiteLLM namespaces and hosts, then allow only approved provider FQDNs/IPs, required package repositories during maintenance windows, and sanctioned observability endpoints. Alert on denied egress rather than silently dropping it.
  6. Reduce stored power. Move provider keys to a secrets manager with short TTL where possible, scope virtual keys by model and budget, disable unused providers, and separate admin credentials from runtime credentials.
  7. Protect the data path. Minimize prompt/response logging, redact secrets and regulated data, encrypt logs at rest, restrict log access, and review retention. Assume gateway logs may be sensitive even when model calls are not.
  8. Add financial and abuse guardrails. Enforce per-key budgets, rate limits, model allow-lists, anomaly alerts on spend, and alerting for sudden shifts to expensive models or unusual geographies.
  9. Hunt before declaring clean. Look back at least 30 days for shell spawns from gateway processes, new virtual keys, model/route changes, callback changes, secret reads, rare outbound destinations, spikes in 401/403 followed by success, and provider billing anomalies.
  10. Escalate if KEV or exploitation evidence appears. If CISA KEV adds either CVE or you find post-exploitation behavior, isolate the gateway, preserve container image and logs, capture memory where feasible, revoke keys, and open an incident under your exploited-vulnerability procedure.

Remediation and hardening baseline

  • Patch: Upgrade to the vendor-confirmed fixed LiteLLM release for CVE-2026-35029 and CVE-2026-59823. Record advisory URL, fixed version, deployment ring, rollback plan, and verification evidence in the change ticket.
  • If you cannot patch immediately: remove public exposure, place the gateway behind authenticated service-mesh or identity-aware proxy controls, disable administrative endpoints, restrict egress to provider endpoints only, rotate keys, increase logging, and set a short exception deadline.
  • Network: default-deny egress; no direct metadata service access unless required; no outbound SMTP or generic internet from the gateway; require TLS verification and block downgrade to plaintext.
  • Identity: dedicated service account, no shared cloud role with broad permissions, no root containers, read-only root filesystem, dropped Linux capabilities, seccomp where supported, and separate namespaces per trust zone.
  • Secrets: no keys in Git, container images, shell history, or plaintext .env files. Mount secrets at runtime, restrict file permissions, and prefer workload identity over static provider keys where the provider supports it.
  • Configuration: disable debug endpoints in production, hide stack traces, require strong authentication for admin and key-management routes, enforce CSRF protection where relevant, and pin model/route changes to version-controlled policy.
  • Monitoring: forward LiteLLM, ingress, ASGI server, container runtime, DNS, and egress firewall logs to the SIEM. Alert on route/config changes, virtual-key creation, callback changes, budget changes, denied egress, and provider error anomalies.
  • Validation: after patching, prove fixed version in every runtime, prove old images are not running, prove denied egress fails closed, prove admin routes require authorization, and run a controlled regression test for OpenAI and Anthropic paths.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

criticalzero-daycvepatch-tuesdayexploitvulnerability-disclosurelitellmcve-2026-35029cve-2026-59823llm-gateway

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.

Book a SOC AssessmentSee AlertMonitor in Action