CVE-2024-6825 & the LiteLLM ecosystem – security audit and technical risk analysis

On 24 March 2026, malicious LiteLLM wheels hit PyPI as versions 1.82.7 and 1.82.8. The story did not start in application code visible on GitHub: attackers had reportedly stolen a PyPI publish token after compromising the CI pipeline (via a Trivy scanner dependency path), then shipped malware that used Python’s .pth startup hook to run before your app imported anything. Same week, defenders were still patching SQL injection, SSRF, and RCE bugs in the gateway itself.

That split—classic CVEs in the proxy versus supply chain in the package—is why this piece exists. LiteLLM is a popular AI gateway: one OpenAI‑compatible front door to 100+ providers. Convenience stacks risk in one place.

Key takeaways

• LiteLLM concentrates API keys, routing, and multi‑tenant admin in one middleware tier (public stats have cited on the order of ~97M monthly PyPI downloads—verify current figures; high blast radius).
• Published issues include RCE, SQLi, SSRF, privilege escalation (internal_user_viewer), DoS (multipart + literal_eval), disclosure, and arbitrary file deletion (catalog below).
• Root causes: dynamic imports (RCE), raw SQL, api_base trust, over‑privileged default tokens, unsafe parsing, weak log masking.
• The March 2026 PyPI incident (TeamPCP, .pth persistence) shows supply chain risk beyond CVE patching.
• Pin versions, rotate secrets, allow‑list egress, parameterize SQL, enforce real RBAC, harden CI.

TL;DR for busy engineers

• Know your version — compare against the CVE table; upgrade to a vendor‑verified build.
• Pin litellm in lockfiles; never pip install litellm unbounded in prod images.
• If you ever installed 1.82.7 / 1.82.8 — assume breach: rotate all secrets, hunt .pth / sysmon.py, rebuild from clean bases.
• Restrict api_base (SSRF); parameterize all DB paths (SQLi); no arbitrary post_call_rules imports (RCE).
• Patch privilege escalation: internal_user_viewer must not receive proxy‑admin tokens (≥ 1.61.15 per advisory).
• DoS surface: upgrade past ast.literal_eval issue (CVE-2024-10188 / GHSA-gw2q-qw9j-rgv7); rate‑limit / bound multipart parsing.
• Egress filter to known LLM endpoints; centralize logs with key masking verified.

Overview

LiteLLM (BerriAI/litellm) is a Python AI gateway and SDK: a proxy (litellm/proxy) adds auth, rate limits, budgets, and routing, while the SDK (litellm/) performs provider calls. Clients typically hit /chat/completions (and friends) on the proxy; the proxy uses the SDK to reach OpenAI, Azure, Anthropic, Vertex, Bedrock, self‑hosted endpoints, and 100+ other backends in an OpenAI‑compatible shape. Admin surfaces cover teams, keys, spend logs, config, optional UI, and integrations (Langfuse, observability). BerriAI also offers an optional LiteLLM Cloud managed service.

Why attackers care: one deployment often holds many provider secrets and sits on the request path for production LLM traffic.

Common deployment patterns

• Self‑hosted — Proxy behind a corporate API gateway / reverse proxy (Kong, NGINX) with TLS, auth, and policy.
• Managed — LiteLLM Cloud as the endpoint (vendor operates parts of the stack).
• Local dev — localhost proxy with weaker controls (don’t treat like prod).

Below: stack diagram, documented CVEs, root causes, exploit sketches, 2026 supply chain, risk, today checklist, and detection—for platform, AppSec, and AI builders who operate the gateway.

How it sits in the stack

+----------------------+     +-------------------------+     +-------------------------------+
| Your apps            |     | LiteLLM proxy           |     | LLM providers                 |
| (services / agents)  | --> | OpenAI-compatible API   | --> | OpenAI, Anthropic, Azure,     |
|                      |     | (routing, keys, spend)  |     | Bedrock, Vertex, Ollama, …    |
+----------------------+     +-------------------------+     +-------------------------------+

Architectural foundation

LiteLLM ships as a Python SDK and a proxy (often “AI Gateway”) on FastAPI, handling concurrent LLM traffic between your code and provider APIs.

Multi‑tenant hierarchy

Enterprise setups partition orgs → teams → users, with virtual keys standing in for real provider keys (scoped by model, budget, expiry).

Config and spend data usually live in PostgreSQL. Provider material is encrypted at rest (SecretBox); keys derive from LITELLM_SALT_KEY / LITELLM_MASTER_KEY via SHA‑256.

Network behavior

The proxy accepts OpenAI‑shape requests, picks a backend, and translates payloads. It may talk to many hosts at once (api.openai.com, regional cloud endpoints, Ollama, etc.) and uses connection pooling to amortize TLS.

Quick terms (for mixed audiences)

Public vulnerability catalog

Middleware that moves fast accumulates injection, SSRF, and disclosure bugs. Summary (as reported in advisories):

These are systemic wherever input hits SQL, filesystem, dynamic code, or outbound HTTP without hard boundaries.

Overlapping releases and CVEs are normal for AI infra. Teams use vendor advisories as source of truth and often add open intel for exploit chatter. VulnSocial is one option for a signal‑heavy, CVE‑centric lens next to NVD and tickets—it does not replace reading patches for your pinned version.

Root causes (why these classes repeat)

RCE (CWE‑94) — CVE-2024-6825

Callbacks on responses imported modules by string—an open importer. Blacklisting os failed; pty.spawn() bypassed it. Fix: whitelist vetted callables only.

Related: CVE-2024-4889 — eval over Google KMS / secret-manager config (attackers usually need high config rights, PR:H). Same lesson: never treat provider secret JSON/YAML as trusted code.

SQLi (CWE‑89)

/key/block, /team/update, /global/spend/logs, and similar paths used raw SQL with concatenated input. Examples: CVE-2024-4890 (user_id) for blind extraction from litellm_params; CVE-2024-5225 (api_key on /global/spend/logs); CVE-2025-45809 (key on /key/block / /key/unblock). Feature velocity + DB‑backed features ⇒ parameterize everything.

SSRF (CWE‑918) — CVE-2024-6587

api_base steered requests to attacker URLs while forwarding Authorization—credential theft. Custom endpoints for self‑hosted models require strict allow‑lists, not “any URL.”

Improper authorization (CWE‑266 / CWE‑285) — CVE-2025-0628

The internal_user_viewer role received a token that behaved like proxy admin: authorization checks on sensitive routes failed, so a low account could invoke /users/*, /team/*, /config/*, and similar PROXY ADMIN operations. Root issue: over‑permissive token tied to a viewer label—defaults and session minting must match least privilege.

Denial of service (CWE‑400)

• CVE-2024-8984 — pathological multipart boundary parsing (extra - characters) tight‑loops CPU/memory.
• CVE-2024-10188 — ast.literal_eval on attacker‑controlled strings is not a safe parser boundary; crafted input exhausts resources or crashes the process (unauthenticated).

Extensibility ⇒ attack surface

Dynamic callbacks, integrations (Langfuse, DB logging), and broad config are product strengths—but each needs sandboxing, validation, and tests, or convenience becomes RCE, SSRF, or disclosure.

March 2026 supply chain attack (technical)

   GitHub Actions CI
          |
          v
   Trivy scan (unpinned / compromised image)
          |
          v
   Runner: code execution
          |
          v
   PYPI_PUBLISH token stolen
          |
          v
   Malicious wheels 1.82.7 / 1.82.8 on PyPI
          |
          v
   pip install (CI / dev / prod image)

Trivy path — Compromised or unpinned Trivy in CI led to runner access and PYPI_PUBLISH theft. Attackers uploaded wheels that never had to match public Git history.

.pth persistence — litellm_init.pth in site‑packages runs at interpreter startup (often subprocess), before import litellm. Double Base64 payload.

Malware layers — (1) dropper + anti‑analysis, (2) harvest SSH, cloud, kube configs, env keys, (3) AES + RSA‑4096, exfil to models.litellm.cloud, sysmon.py via systemd.

Industry reporting described a short PyPI exposure window and very high normal download velocity for the package—small timing errors in pinning can hit a huge audience.

Exploitation scenarios

1 — SSRF → steal provider key (CVE-2024-6587)

Attacker POSTs /chat/completions (or equivalent) with api_base pointing at a collector they control. The proxy forwards the LLM request and typical auth headers; the collector logs the API key.

2 — Secrets via SQLi (CVE-2024-4890)

Vulnerable /team/update. Steps: fingerprint version → use low‑priv team key → time‑based blind SQLi on user_id to recover LITELLM_MASTER_KEY / litellm_params — e.g.:

') UNION SELECT (CASE WHEN (substr((SELECT litellm_params FROM LiteLLM_ProxyModelTable LIMIT 1),1,1)='s') THEN pg_sleep(5) ELSE pg_sleep(0) END)--

Then decrypt stored provider keys.

Variant — /key/block / SQLi (CVE-2025-45809): crafted key parameter embedded in raw SQL can destroy or dump tables holding tenants and credentials.

3 — “Viewer” → admin (CVE-2025-0628)

User with internal_user_viewer logs in and receives an admin‑capable bearer token. They call e.g. GET /users/list with Authorization: Bearer … and enumerate identities, then /team/create, /config/update, or key routes to own the tenant.

4 — Cluster pivot via bad package

Unpinned pip install litellm pulls 1.82.8 → .pth runs → steal K8s service account token → read Secrets → optional privileged pods / host sysmon.py.

Attack surface (at a glance)

Log disclosure plus admin bugs often chain to RCE.

Risk matrix

Worst‑case chain (illustrative)

   (A) SSRF: stolen provider key (CVE-2024-6587)
                    \
   (B) Viewer→admin token (CVE-2025-0628) ---> combined with SQLi / admin routes
                    /
                    v
          DB + master key (e.g. SQLi CVE-2024-5225, CVE-2025-45809, …)
                    |
                    v
          RCE via post_call_rules (CVE-2024-6825)
                    |
                    v
          Cloud / K8s / SSH harvest

1. Initial access: SSRF key theft or CVE-2025-0628‑style admin API use (often plus SQLi on /global/spend/logs or /key/*).
2. Credential depth: LITELLM_MASTER_KEY, connection strings, or provider material from the DB.
3. RCE: malicious post_call_rules.
4. Impact: metadata, SSH, cluster.

What to do today (checklist)

• Inventory every LiteLLM version in prod, CI, and devcontainers.
• Upgrade to a verified release; for RCE follow vendor floor (e.g. ≥ 1.67.4‑stable where applicable).
• Pin exact versions in requirements / lockfiles; verify hashes or internal mirror.
• If 1.82.7 / 1.82.8 ever ran — rotate everything, delete .pth / sysmon.py, audit systemd.
• Allow‑list api_base targets; parameterize SQL; restrict who can edit callbacks.
• Upgrade ≥ 1.61.15 (or current vendor floor) if internal_user_viewer is used; audit tokens for admin scope.
• Patch DoS: multipart fixes (CVE-2024-8984); literal_eval fix path (CVE-2024-10188 / GHSA-gw2q-qw9j-rgv7).
• Egress only to known LLM endpoints; WAF where possible.
• Log to SIEM with masking proven on real traffic.

Mitigation and hardening

Compromised supply chain — Treat host as owned; full secret rotation; rebuild from known‑good base images.

Patching — Move to ≥ 1.82.9 (or pin 1.82.6 if policy requires) for the 2026 supply chain; separately verify floors for SSRF (e.g. ≥ 1.44.8), SQLi /key/* (≥ 1.81.0), viewer auth (≥ 1.61.15), multipart DoS (≥ 1.56.2), /health leak (≥ 1.63.14), Langfuse errors (≥ 1.52.2+ per advisory), log masking (≥ 1.44.12), and RCE post_call_rules (vendor stable line).

Config — Parameterized queries only (CVE-2024-4890, CVE-2024-5225, CVE-2025-45809). Allow‑list api_base (CVE-2024-6587). No literal_eval / unsafe eval on user input (CVE-2024-10188). Role‑aligned tokens only—never admin material for viewer (CVE-2025-0628). Patch logging disclosure CVEs (CVE-2024-9606, CVE-2025-0330, CVE-2025-11203). Tight RBAC on global config (CVE-2024-6825). Size/time limits on multipart.

Infrastructure — Prefer Vault / Secrets Manager over DB‑only secrets. Protect LITELLM_SALT_KEY / LITELLM_MASTER_KEY with KMS or CI secrets.

Deployment — Prefer not exposing LiteLLM raw to the internet: API gateway / reverse proxy with TLS, IP allow‑lists, rate limits. Official images (ghcr.io/berriai/litellm), non‑root, read‑only root FS where possible, signed artifacts, private PyPI mirror with review.

Detection and hunting

Rules of thumb — SQLi patterns in params (pg_sleep, UNION); post_call_rules touching pty, subprocess; Python workers spawning shells; DNS to young typosquat domains. Alerts: internal_user_viewer sessions calling /users/*, /config/*, or other admin‑only routes; CPU spikes on literal_eval / multipart paths; egress to non‑provider hostnames right after api_base-style requests.

LLM middleware in context

Upstream tool compromise (Trivy, small deps) to hit downstream AI packages is the new normal—.pth is especially nasty because it bypasses import‑based scanning. Map trust and pins for the whole pipeline, not only the gateway repo.

Bottom line

LiteLLM is worth attacking because it holds the keys to your AI bill and data plane. Application CVEs (RCE, SQLi, SSRF, viewer→admin, DoS, disclosure) show recurring input, authorization, and trust bugs; the 2026 PyPI episode shows distribution can beat source review. Patch, pin, rotate, segment, monitor—as one program.

#hashtags: #CVE20246825 #CVE20250628 #CVE202410188 #LiteLLM #BerriAI #AIGateway #SQLInjection #SSRF #RCE #SupplyChain #PyPI #ThreatHunting #DevSecOps