Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
LiteLLM is not automatically safe to run without version and supply-chain controls. The open-source Python gateway has disclosed remote-code-execution, denial-of-service, SQL-injection, SSRF, arbitrary-file-read and privilege-escalation flaws. In a separate March 24, 2026 supply-chain incident, malicious PyPI packages numbered 1.82.7 and 1.82.8 and were available for about 40 minutes. Operators should inventory every installation, determine whether either package was installed or imported, upgrade to clean releases, and rotate any credentials the gateway could access.
Why a LiteLLM compromise can affect more than one service
LiteLLM provides a common Python interface and proxy for sending requests to multiple AI model providers. The proxy can route traffic, expose an administrative API and hold provider credentials. That combination makes a vulnerable gateway a high-value target: an attacker may reach the process itself, its management database, the host filesystem or secrets available to the runtime.
Download statistics show the potential scale, not the number of victims. BlackSwan Cybersecurity reported more than 95 million monthly PyPI downloads in 2026; that figure counts downloads, not unique installations or compromised users. CloudSEK, in figures reported by ITPro in 2026, said more than 2,500 organizations were exposed. “Exposed” does not prove that those organizations were breached.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The March 2026 PyPI supply-chain incident
Which packages were malicious?
BerriAI’s incident report states: “The compromised PyPI packages were litellm==1.82.7 and litellm==1.82.8.” The packages were live for roughly 40 minutes on March 24, 2026, before quarantine. The report says the code searched for environment variables, SSH keys, AWS, Google Cloud and Azure credentials, Kubernetes tokens and database passwords, and could encrypt and exfiltrate collected data.
#1 Best Overall
Was every deployment affected?
No. BerriAI said, “Customers running the official LiteLLM Proxy Docker image were not impacted.” The incident specifically separated that pinned image and source installations from the compromised, unpinned PyPI path. This is not a blanket guarantee for every container or source build: operators still need to verify the image digest, build inputs and runtime credentials.
LiteLLM vulnerability timeline
| Issue | What an attacker could do | Version detail |
|---|---|---|
| CVE-2024-4264 | Unsafe use of eval in litellm.get_secret() enabled remote code execution. |
The cited GitHub advisory does not state a fixed version. |
| CVE-2024-8984 | An unauthenticated denial-of-service condition affected the proxy. | Affected LiteLLM version: 1.44.5. |
| March 24, 2026 supply-chain incident | Malicious package code harvested secrets and could encrypt and exfiltrate data. | 1.82.7 and 1.82.8; active for about 40 minutes. |
| CVE-2026-42208 | A crafted Authorization header reached SQL-injection-prone API-key verification through an error path, potentially exposing or modifying proxy database data. |
Fixed in 1.83.7. |
| CVE-2026-59823 | An authenticated caller could place api_base in user_config, making the proxy send requests to an arbitrary host. |
Fixed in 1.83.9. |
| Arbitrary local file read | An authenticated internal_user_viewer could abuse vertex_ai_credentials to read files accessible to the process. The advisory warns that /proc/self/environ can reveal LITELLM_MASTER_KEY and provider keys. |
Fixed in 1.95.0. |
| September 2026 privilege-escalation advisory | An authenticated internal user could reuse the salt key to become proxy_admin, then obtain command execution through the MCP stdio endpoint. |
The cited advisory does not provide a CVE number or fixed version. |
How to check whether 1.82.7 or 1.82.8 was installed
Check every place LiteLLM can run: production hosts, proxy containers, virtual environments, CI runners, developer laptops and dependency caches. A clean result on one machine does not clear another environment.
- On each Python environment, run
python -m pip show litellm python -m pip freeze | grep -i '^litellm=='On Windows PowerShell, use
python -m pip freeze | Select-String -Pattern '^litellm=='. - Confirm the imported package rather than only the package-manager record:
python -c "import litellm; print(getattr(litellm, '__version__', 'version not exposed')); print(litellm.__file__)"The path tells you which virtual environment or image supplied the module.
- Inspect lockfiles, wheel caches, Docker image layers and CI artifacts for the exact strings
litellm==1.82.7andlitellm==1.82.8. - Review package-install, proxy, CI/CD and outbound-network logs for the March 24, 2026 window described in BerriAI’s report. If the package was installed but never executed, the risk differs from a running process; preserve those records before rebuilding.
What to do if an affected package or exploit path is possible
- Contain first. Isolate the host, container or runner from unnecessary network access while preserving logs, filesystem images and package metadata.
- Rebuild from a clean source. Do not simply overwrite files in a potentially compromised environment. Use a verified release and a fresh virtual environment or image.
- Meet every applicable fixed version. Use LiteLLM
1.83.7or newer for CVE-2026-42208,1.83.9or newer for CVE-2026-59823, and1.95.0or newer for the arbitrary-file-read issue. These minimums do not by themselves remediate the separate malicious-package incident or every older advisory. - Rotate secrets that the process could reach. Replace provider API keys, the LiteLLM master key, cloud credentials, SSH keys, Kubernetes tokens and database passwords when an affected package ran or when the file-read path may have been reachable. Revoke old credentials, not just copy new values into the same environment.
- Hunt for use of stolen credentials. Check cloud audit trails, model-provider usage, database authentication, Kubernetes activity, SSH logins and unusual outbound connections for the period beginning before detection and extending through credential revocation.
- Harden the next deployment. Pin dependencies, verify release hashes or signatures where available, isolate build jobs, generate an SBOM and monitor dependency changes continuously.
Choosing a deployment path after the incident
| Deployment path | What the March incident established | Controls to verify |
|---|---|---|
| Official LiteLLM Proxy Docker image | BerriAI reported that customers running it were not impacted by the compromised PyPI packages. | Pin the image digest, review included dependencies and restrict the management plane. |
| PyPI installation | The unpinned PyPI path contained the malicious 1.82.7 and 1.82.8 releases. |
Use a lockfile, verify artifacts and record installation provenance in CI and production. |
| Source installation | BerriAI distinguished source installations from the compromised unpinned PyPI path. | Reproduce builds, pin dependencies, retain commit and artifact hashes, and scan the resulting SBOM. |
Regardless of packaging, keep the proxy management interface behind authentication and network controls, minimize the credentials available to the process, and treat every upgrade as a supply-chain change that needs review.
What “safe” means for a LiteLLM operator
There is no single safe-version answer because the exposure depends on both the vulnerability and the way LiteLLM was installed. A current release can still be deployed unsafely if old credentials remain valid, the management plane is exposed, or dependencies are unpinned. Conversely, a pinned image that avoided the March package incident still needs the patched versions for the SQL-injection, SSRF and file-read advisories where those conditions apply.
Rank #3
The practical standard is evidence: prove which artifact ran, when it ran, what it could read, and whether its credentials were used. If that proof is unavailable for an environment containing 1.82.7, 1.82.8 or an exposed vulnerable proxy, handle the environment as potentially compromised and complete containment, rebuild and rotation rather than relying on a version check alone.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
