TL;DR
- 47,000 downloads in 46 minutes: Two malicious versions of LiteLLM (1.82.7 and 1.82.8) were downloaded nearly 47,000 times before PyPI quarantined them on March 24, 2026 [1]
- 2,337 dependent packages at risk: 88% of packages depending on LiteLLM had version specifications that allowed the compromised versions [2]
- Automatic credential theft: The malware harvested SSH keys, cloud credentials (AWS/GCP/Azure), .env files, Kubernetes configs, and cryptocurrency wallets on every Python startup [3]
- No user action required: The .pth file payload executed during
pip installitself — before any application code ran [4] - Business takeaway: Pin your dependencies, scan for vulnerable packages, and audit your Python environments now
What Happened: The LiteLLM Attack Timeline
On March 24, 2026, a supply chain attack targeting the popular Python package LiteLLM demonstrated how quickly malware can spread through modern software ecosystems. The attack window lasted just 46 minutes, but the impact reached thousands of development environments worldwide [1].
Free Resource
Weekly Threat Briefing — Free
Curated threat intelligence for Australian SMBs. Active campaigns, new CVEs, and practical mitigations — every week, straight to your inbox.
Subscribe Free →At 10:39 UTC, attackers uploaded LiteLLM version 1.82.7 to the Python Package Index (PyPI). Thirteen minutes later, at 10:52 UTC, version 1.82.8 followed. Neither version had a corresponding tag on the official GitHub repository — a red flag that went unnoticed until it was too late. By 11:25 UTC, PyPI administrators had quarantined both versions after receiving reports from security researchers at FutureSearch [1][5].
The scale of exposure was staggering. During those 46 minutes, the two malicious versions accumulated 46,996 downloads. Version 1.82.8 alone accounted for 32,464 downloads, with 23,142 via pip and 8,901 via uv [2]. Every single pip install of version 1.82.8 executed the malware payload during installation itself.
How the Attack Worked
The attackers used two different techniques across the two versions, each targeting different deployment scenarios [3].
Version 1.82.8 included a malicious .pth file named litellm_init.pth. Python executes .pth files automatically on interpreter startup, including during package installation. This meant the payload ran before any application code had a chance to intervene. The act of running pip install litellm was enough to trigger the attack [3].
Version 1.82.7 injected a payload into proxy_server.py that dropped a secondary script called p.py. This version only activated when litellm.proxy was imported, primarily affecting proxy server deployments rather than general SDK usage [3].
Both versions harvested the same sensitive materials: SSH private keys, cloud provider credentials (AWS, GCP, Azure), .env configuration files, Kubernetes cluster configurations, cryptocurrency wallet files, shell command history, and environment variables [3][6].
The stolen data was exfiltrated to attacker-controlled servers. Version 1.82.7 sent data to checkmarx[.]zone/raw, while version 1.82.8 used models[.]litellm[.]cloud [3].
Why This Matters for Small Businesses
Supply chain attacks are particularly dangerous because they exploit trust relationships rather than technical vulnerabilities. LiteLLM is a legitimate package used by thousands of developers to standardize API calls across different AI model providers. Organizations using it had no reason to suspect it contained malware [7].
According to the 2025 Cost of a Data Breach Report, supply chain attacks cost organizations an average of $4.76 million per incident and take 292 days to identify and contain [8]. For small businesses without dedicated security teams, the discovery timeline can stretch even longer.
The LiteLLM attack demonstrates several critical risks:
Automated CI/CD pipelines are vulnerable. A continuous integration pipeline that ran pip install litellm during the 46-minute window was compromised even if it never executed application code. Build systems, deployment pipelines, and development containers all become attack vectors [3].
Transitive dependencies multiply exposure. The researchers identified 2,337 packages on PyPI that list LiteLLM as a dependency. Of those, 2,054 (88%) had version specifications that allowed the compromised versions. A developer installing an unrelated package could unknowingly trigger the malware through transitive dependencies [2].
Cloud credentials are high-value targets. The malware specifically targeted AWS, GCP, and Azure credentials. For businesses running workloads in the cloud, stolen credentials can lead to infrastructure takeover, data exfiltration, and cryptocurrency mining on your billing account [6].
ISO 27001 SMB Starter Pack — $97
Threat intelligence is one thing — having the policies and controls to respond is another. Get the complete ISO 27001 starter kit for SMBs.
Get the Starter Pack →Detection and Response: A 72-Minute Disclosure
The response to this attack showcases how AI-assisted security research can accelerate incident response. Callum McMahon, the engineer at FutureSearch who first identified the malware, documented a 72-minute timeline from initial detection to public disclosure [5].
The investigation began when McMahon noticed unusual process behavior on his laptop — 11,000 Python processes spawned by a fork bomb. Initial investigation assumed a runaway development tool, but deeper analysis with Claude Code revealed the malicious .pth file [5].
Within 27 minutes of identifying the malware, McMahon confirmed it was actively live on PyPI by downloading the package in an isolated Docker container. The disclosure blog post was written, reviewed, and published in just three minutes using AI assistance. The post was then shared with r/Python, r/netsec, and r/LocalLLaMA for maximum visibility [5].
This rapid response likely limited the attack's spread. Traditional vulnerability disclosure timelines often stretch across days or weeks. The compressed 72-minute window demonstrates how AI tools can help security researchers move at machine speed.
What Your Business Should Do Now
If your organization used LiteLLM or any package depending on it between March 24, 2026 and the present, take immediate action [9]:
1. Audit your dependency tree. Run pip show litellm or check your lock files to identify if you installed versions 1.82.7 or 1.82.8. Tools like pip-audit and safety can scan for known vulnerable packages [10].
2. Rotate all credentials. Assume any credentials present in your development environment during the attack window were compromised. Rotate SSH keys, cloud access keys, API tokens, and database passwords.
3. Review access logs. Check your cloud provider's access logs for any unusual activity originating from unexpected IP addresses or during unusual hours.
4. Pin your dependencies. Use exact version pinning in your requirements files (e.g., litellm==1.80.0) rather than allowing version ranges. This prevents automatic upgrades to malicious versions [11].
5. Implement dependency scanning. Add automated dependency scanning to your CI/CD pipeline. Tools like Dependabot, Snyk, and pip-audit can alert you to vulnerable packages before they reach production [10][12].
The Bigger Picture: Software Supply Chain Security
The LiteLLM attack is part of a broader trend of supply chain compromises targeting open-source ecosystems. According to the Open Source Security Foundation, supply chain attacks increased 742% between 2019 and 2025 [13].
Python's PyPI, JavaScript's npm, and other package registries have become attractive targets because they offer direct access to millions of development environments. A single compromised package can propagate to thousands of downstream users within hours [14].
The industry response has included improved package signing (Sigstore's cosign), registry-level malware scanning (PyPI's malware detection), and supply chain security frameworks like SLSA (Supply-chain Levels for Software Artifacts) [15]. However, adoption remains uneven, and attackers continue to find gaps in the supply chain.
For small businesses, the key takeaway is that you inherit the security posture of every package in your dependency tree. Treating third-party dependencies as untrusted code — and implementing appropriate controls — is no longer optional.
FAQ
Check your pip cache, lock files, and deployment logs for any installations of litellm versions 1.82.7 or 1.82.8 between March 24, 2026 and present. You can run pip show litellm to see your installed version, or check requirements.lock or poetry.lock files for historical installations.
The attack used a .pth file, which Python automatically executes on interpreter startup. This meant the malware ran during pip install itself — before any application code could intervene. Users didn't need to run any code; installation alone was sufficient for compromise.
Pin dependencies to exact versions, implement automated dependency scanning in your CI/CD pipeline, use lock files consistently, and subscribe to security advisories for packages you depend on. Consider using tools like pip-audit, Snyk, or Dependabot for continuous monitoring.
No. The researchers identified 2,337 packages on PyPI that depend on LiteLLM, and 88% had version specifications that allowed the compromised versions. If you installed any package that transitively depended on LiteLLM during the attack window, you may have been affected.
The malware harvested SSH private keys, AWS/GCP/Azure cloud credentials, .env files containing secrets, Kubernetes cluster configurations, cryptocurrency wallet files, shell history, and environment variables. If any of these were present in your environment during the attack window, assume they were compromised.
References
[1] C. McMahon, "My minute-by-minute response to the LiteLLM malware attack," FutureSearch Blog, Mar. 25, 2026. [Online]. Available: https://futuresearch.ai/blog/litellm-attack-transcript/
[2] D. Hnyk, "LiteLLM Hack: Were You One of the 47,000?," FutureSearch Blog, Mar. 25, 2026. [Online]. Available: https://futuresearch.ai/blog/litellm-hack-were-you-one-of-the-47000/
[3] C. McMahon, "Supply Chain Attack in litellm 1.82.8 on PyPI," FutureSearch Blog, Mar. 24, 2026. [Online]. Available: https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack
[4] C. McMahon, "No Prompt Injection Required," FutureSearch Blog, Mar. 24, 2026. [Online]. Available: https://futuresearch.ai/blog/no-prompt-injection-required
[5] FutureSearch, "LiteLLM Attack Timeline and Response," FutureSearch Blog, Mar. 25, 2026. [Online]. Available: https://futuresearch.ai/blog/litellm-attack-transcript/
[6] Python Packaging User Guide, "Python .pth files and import hooks," Python Packaging Authority, 2025. [Online]. Available: https://packaging.python.org/en/latest/specifications/
[7] LiteLLM Documentation, "LiteLLM - Getting Started," BerriAI, 2026. [Online]. Available: https://docs.litellm.ai/
[8] IBM Security, "Cost of a Data Breach Report 2025," IBM, 2025. [Online]. Available: https://www.ibm.com/reports/data-breach
[9] Python Packaging Authority, "Dependency Management Best Practices," PyPA, 2025. [Online]. Available: https://packaging.python.org/en/latest/guides/
[10] PyPI, "pip-audit: A tool for scanning Python environments for vulnerable packages," Python Packaging Authority, 2026. [Online]. Available: https://pypi.org/project/pip-audit/
[11] S. Wright, "Why You Should Pin Your Dependencies," Hynek Schlawack Blog, 2024. [Online]. Available: https://hynek.me/articles/python-pins/
[12] Snyk, "Open Source Security Management," Snyk Ltd., 2026. [Online]. Available: https://snyk.com/learn/open-source-security/
[13] Open Source Security Foundation, "Securing the Open Source Software Supply Chain," OpenSSF, 2025. [Online]. Available: https://openssf.org/
[14] Sonatype, "State of the Software Supply Chain Report 2025," Sonatype Inc., 2025. [Online]. Available: https://www.sonatype.com/state-of-the-software-supply-chain
[15] Google, "SLSA: Supply-chain Levels for Software Artifacts," Google Open Source, 2025. [Online]. Available: https://slsa.dev/
Concerned about your software supply chain security? lilMONSTER helps small businesses implement dependency scanning, credential management, and incident response plans. Book a consultation to secure your development pipeline.
Work With Us
Ready to strengthen your security posture?
lilMONSTER assesses your risks, builds the tools, and stays with you after the engagement ends. No clipboard-and-leave consulting.
Book a Free Consultation →TL;DR
- Someone hid bad code in a popular AI tool called LiteLLM
- 47,000 people downloaded it before anyone noticed
- The bad code stole passwords and keys from computers automatically
- You can protect yourself by checking your software and changing your passwords
What Happened? (Like You're 10)
Imagine you order a pizza from your favorite restaurant. The delivery driver brings it to your house, you pay, and you eat it. Everything seems normal.
But what if someone had poisoned the pizza ingredients at the factory before they even reached the restaurant? The restaurant made the pizza perfectly — they just couldn't see the poison hidden inside.
That's what happened with LiteLLM.
LiteLLM is like a "universal remote" for AI — it helps companies use different AI tools (like ChatGPT, Claude, and others) without rewriting their code each time. It's very popular because it saves developers a lot of time [1].
On March 24, 2026, bad guys managed to sneak a "poisoned" version of LiteLLM onto the website where developers download it. For 46 minutes, anyone who downloaded LiteLLM got the poisoned version instead of the safe one [2].
How Did They Sneak It In?
Think of it like this:
- The real LiteLLM is like a recipe book that helps you cook with different AI ingredients
- The bad guys added a secret page to the recipe book
- That secret page said: "Before you start cooking, copy all the keys and passwords from this house and send them to me"
- The copying happened automatically — you didn't have to do anything wrong
The bad guys used something called a .pth file. In Python (the programming language LiteLLM is written in), .pth files run automatically whenever Python starts. It's like hiding instructions in a book that make you do something every time you open the book, not just when you read that specific page [3].
What Did the Bad Guys Steal?
The poisoned code looked for and stole [2]:
- SSH keys — These are like special keys that let you unlock servers remotely. It's like giving someone the key to your office building.
- Cloud credentials — Passwords for services like Amazon Web Services, Google Cloud, and Microsoft Azure. These can cost you real money if bad guys use your account.
- Environment variables — Secret settings that often contain passwords and API keys.
- Cryptocurrency wallets — If you had any crypto on your machine, the malware looked for it.
- Kubernetes configs — Settings for managing cloud applications.
How Many People Were Affected?
The numbers are pretty big [2]:
- 47,000 downloads in just 46 minutes
- 2,337 other software packages depend on LiteLLM (meaning if you installed one of them, you might have gotten the poisoned LiteLLM too)
- 88% of those packages were set up in a way that would automatically get the poisoned version
How Do You Know If You Were Affected?
If you use Python and installed anything between March 24-25, 2026, check:
- Run this command:
pip show litellm - Look at the version number
- If it says 1.82.7 or 1.82.8, you downloaded the poisoned version
What Should You Do If You Were Affected?
If you think you might have been affected, here's your action plan:
- Change all your passwords — Especially for cloud services (AWS, Google Cloud, Azure) and any databases
- Generate new SSH keys — The old ones might have been stolen
- Check your cloud bills — Look for any unusual activity
- Update LiteLLM — Get the latest safe version
- Tell your IT person — If you have one, they need to know
How Can You Prevent This in the Future?
Here are some simple ways to protect yourself:
Pin your versions — Instead of saying "give me the latest LiteLLM," say "give me LiteLLM version 1.80.0 exactly." This prevents auto-updates to bad versions [4].
Use a lock file — Tools like
pip freeze > requirements.txtsave the exact versions you're using. This acts like a receipt showing exactly what you installed.Scan your dependencies — Tools like
pip-auditcan check your installed packages against a database of known bad versions [5].Don't store secrets in code — Use environment variables or secret managers instead of putting passwords directly in your code.
Keep backups — If something goes wrong, you want to be able to restore from a known-good state.
The Good News
The security researchers at FutureSearch found the problem quickly and told PyPI (the Python package repository) within hours. PyPI removed the bad versions within 46 minutes [6].
The researchers also documented exactly how they found the problem and fixed it, which helps everyone learn how to respond faster next time.
FAQ
Yes! The bad versions (1.82.7 and 1.82.8) have been removed from PyPI. You can safely install LiteLLM now — just make sure you're getting the latest version, which has been cleaned up [7].
If your business doesn't use Python, you weren't affected by this specific attack. However, similar supply chain attacks have happened in other programming languages like JavaScript (npm packages) and Ruby (RubyGems). The same protection principles apply [8].
You probably won't know immediately. The malware ran silently in the background. The safest approach is to assume any password that was on your computer during the attack window was compromised and change it.
Unfortunately, no. Supply chain attacks are becoming more common. In 2024, attackers compromised the colors and faker npm packages, affecting millions of downloads. The trend is increasing, which is why learning to protect yourself is so important [8].
No! Open-source packages are still generally safe and provide huge value. The key is to use them carefully: pin your versions, scan for vulnerabilities, and keep your dependencies updated. The benefits far outweigh the risks when you follow good practices [9].
References
[1] LiteLLM Documentation, "LiteLLM - Getting Started," BerriAI, 2026. [Online]. Available: https://docs.litellm.ai/
[2] D. Hnyk, "LiteLLM Hack: Were You One of the 47,000?," FutureSearch Blog, Mar. 25, 2026. [Online]. Available: https://futuresearch.ai/blog/litellm-hack-were-you-one-of-the-47000/
[3] C. McMahon, "Supply Chain Attack in litellm 1.82.8 on PyPI," FutureSearch Blog, Mar. 24, 2026. [Online]. Available: https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack
[4] S. Wright, "Why You Should Pin Your Dependencies," Hynek Schlawack Blog, 2024. [Online]. Available: https://hynek.me/articles/python-pins/
[5] PyPI, "pip-audit: A tool for scanning Python environments for vulnerable packages," Python Packaging Authority, 2026. [Online]. Available: https://pypi.org/project/pip-audit/
[6] C. McMahon, "My minute-by-minute response to the LiteLLM malware attack," FutureSearch Blog, Mar. 25, 2026. [Online]. Available: https://futuresearch.ai/blog/litellm-attack-transcript/
[7] PyPI, "LiteLLM Package History," Python Package Index, 2026. [Online]. Available: https://pypi.org/project/litellm/
[8] Sonatype, "State of the Software Supply Chain Report 2025," Sonatype Inc., 2025. [Online]. Available: https://www.sonatype.com/state-of-the-software-supply-chain
[9] Open Source Security Foundation, "Securing the Open Source Software Supply Chain," OpenSSF, 2025. [Online]. Available: https://openssf.org/
Worried about software supply chain attacks? lilMONSTER helps small businesses secure their development tools and respond to security incidents. Book a consultation to protect your business.