LiteLLM Enterprise Advisory Flags Unauthenticated File Read Flaw

What changed

On 27 October 2026 GitHub published a critical LiteLLM security advisory. The summary states an open file read on Enterprise licensed LiteLLM proxy routes can leak secrets without a login. An attacker can trick the proxy into reading a local file and posting contents to a chosen URL.

Reading paths such as proc self environ can expose LITELLM MASTER KEY and provider API keys. That access can grant full admin control of the proxy. Some setups may allow further code run as root after keys leak.

Open source LiteLLM without an active Enterprise license is not affected because the vulnerable code loads only with Enterprise enabled. Patched versions include 1.103.10 and newer per the advisory.

Why it matters

Many teams use LiteLLM as a central gate to model vendors. One open LLM route flaw can expose every API key stored on that host.

Paid Enterprise features often run on internal nets that still face abuse from bad apps or open ports. Treat the critical advisory as a same week patch job, not a next sprint task.

The advisory also lists edge blocks on certain JSON keys, tight outbound rules, and storing master keys in a secret store instead of plain env files.

Who is affected

Platform engineers running LiteLLM Enterprise proxies. Red teams testing AI gateways. SOC analysts monitoring odd outbound POSTs from inference subnets. Vendors who resell managed LiteLLM installs to regulated clients.

What to do next

Confirm whether Enterprise licensing is active on any exposed proxy. Upgrade to at least 1.103.10 and rotate all provider keys and master keys after patch.

If you cannot patch immediately, apply WAF or ingress rules that reject POST bodies containing standard callback dynamic params, gcs path service account, callbacks, success callback, or failure callback keys as listed in the advisory.

What to watch

Watch LiteLLM release tags after 1.103.10 for follow on hardening. Watch your egress logs for unexpected POSTs from proxy hosts to unknown domains.

Photo: Tima Miroshnichenko / Pexels

Assume compromise if your proxy was internet reachable on vulnerable builds. Rotate keys even after patch and review admin audit logs for new users or callbacks.

Photo: Karolina Grabowska / Pexels

Keep proxies off the public internet where possible. Use VPN, mTLS, or authenticated ingress in front of any route that accepts model traffic.

Credit for discovery belongs to independent reporters named in the advisory. Thank them by documenting your timeline when you close incidents.

Split prod and staging keys before rotation so a staging mistake does not take down live chatbots. Many teams reuse keys for speed and regret it during incidents.

Add a health check that fails if Enterprise license files appear on open source only hosts. That catches mistaken image tags early.

Train support staff not to paste full error JSON from proxies into public tickets. Those blobs can include callback fields attackers probe.

Run a five minute scan for proxies listening on 0.0.0.0 with Enterprise license env vars set. Move them behind auth first, patch second.

Add alerts when new admin users appear on LiteLLM dashboards. Key theft often shows up as a quiet role change before exfil.

Review backup images for old keys still on disk. Rotation fails if a restored VM brings back stale env files.

Print the patched version on your internal status page when done. Execs calm down when the number is visible.

File a short postmortem even if you found no abuse. Lessons help the next gateway upgrade go smoother.

Test patch roll forward on a clone host before you touch the prod proxy during business hours.

Sources

• Primary — BerriAI, LiteLLM security advisory on file read flaw (27 October 2026). Summary, affected versions, and mitigations.
• Secondary — BerriAI, LiteLLM repository (31 October 2026). Release context for Enterprise proxy deployments.