One of my colleague, Rohan pinged me on a Tuesday night. “Bro, we just found litellm 1.82.8 in three of our client repos. What do I even tell them?”
He’s a fresher I mentor, six weeks into his first SOC job. This was his first real incident, not a lab, not a walkthrough video. So let’s break down what actually happened with LiteLLM, because if you’re prepping for a SOC analyst role right now, this case is going to show up in interviews for the next year.
What LiteLLM even is
If you have zero context about it, in simple terms, LiteLLM is the library developers use to call any LLM (OpenAI, Anthropic, Azure, whatever) through one unified API instead of juggling five different SDKs. It sits inside agentic apps, internal tools, CI pipelines, basically anywhere a team is experimenting with AI. Around 95 million downloads a month. That number matters for what comes next.
The attack chain, not just the breach
The part that most people get wrong when they talk about this is that it wasn’t “LiteLLM got hacked.” LiteLLM was the third domino.
On March 19, 2026, a group tracked as TeamPCP compromised Aqua Security’s Trivy, the vulnerability scanner half the industry runs inside CI/CD pipelines. They force pushed malicious commits across nearly every version tag of trivy-action and setup-trivy, so any pipeline pinning by tag instead of commit SHA pulled the poisoned build on its next run(sort of process injection).
LiteLLM’s own CI used Trivy for scanning. When that flawed scanner ran inside their pipeline, it quietly harvested a PyPI publishing token. Three days later, on March 24, TeamPCP used that stolen token to push two backdoored releases straight to PyPI: 1.82.7 and 1.82.8. No repo compromise needed.
Rohan’s client environments hadn’t been “attacked” in the way he was trained to think about it. Nobody phished anyone. Nobody exploited a CVE in their own code. A trusted dependency, three layers upstream, did the exploiting for them.
What the payload actually did
The malicious code sat in a single file inside the wheel, litellm/proxy/proxy_server.py, twelve lines inserted between two unrelated legitimate blocks. Easy to miss in a diff if you’re not specifically looking.
Once it ran, it went after SSH keys, AWS and GCP and Azure credentials, Kubernetes configs, git credentials, every environment variable it could reach (which for most teams means every API key), shell history, and CI/CD secrets. Version 1.82.8 added a “.pth” file injection trick for persistence. TeamPCP claimed over 300GB exfiltrated. Nobody's independently verified that number, but even a fraction of it across 2,500+ organizations and roughly 430,000 CI/CD pipelines is not a small incident.
The whole thing was live on PyPI for about three hours before it got pulled. Three hours, 95 million monthly downloads. Do that math.
And the detail I keep coming back to was, discovered almost by accident. A researcher named Callum McMahon had litellm pulled in as a transitive dependency through an MCP plugin, and his machine ran out of RAM and crashed during install. A bug in the malware is what surfaced the whole campaign. If the payload had been a little cleaner, this stays undetected for weeks.
What I’d tell Rohan to actually check
I don’t do the “here are 10 things to remember” listicle thing with my mentees, because in a real incident you don’t remember lists, you remember what to look for. So this is what we walked through:
- Any environment that touched 1.82.7 or 1.82.8 gets treated as fully compromised, not “possibly affected.” Every secret that library could reach, in process memory, on disk, injected into a CI job, pulled from instance metadata, gets rotated. Not reset. Rotated, with the old one revoked.
- Check for the litellm_init.pth file as a compromise indicator. Look at outbound traffic to unfamiliar domains around the install window. And if you're in Kubernetes, check for lateral movement attempts, because that was one of the three stages of the payload.
The bigger lesson for Rohan, and honestly for me, is that “we scan our dependencies” isn’t a security control anymore if the scanner itself can be the attack vector. Trivy was the trusted tool. That’s exactly why it got targeted first.
Why this matters if you’re job hunting right now
I’ve sat in a few MDR interviews this year where the interviewer asked some version of “walk me through how you’d investigate a compromised third party library in a CI pipeline.” Before LiteLLM, that question felt theoretical. It isn’t anymore. If you can talk through this incident specifically, the credential theft chain from Trivy to LiteLLM, the problem, the difference between “patch the version” and “assume every secret is burned,” you’re already ahead of most candidates who’ll mumble something generic about “following NIST guidelines.”
That’s the actual skill gap in this market. Not knowing more tools. Knowing how to reason through an incident nobody wrote a walkthrough for yet.
If you want to practise this kind of thinking before your first role, my Cybersecurity Foundations course is built around exactly this. Real scenarios, investigation-first, no tool tutorials.
👉 Cybersecurity Foundations Course
Want me to review your resume or talk through where you’re stuck?
👉 SOC Resume Review
👉 Career Clarity Call
For a weekly breakdown on real SOC workflows and how to prepare for them:
— Manubhav Sharma
Threat Analyst at Sophos · Follow on LinkedIn
What is LiteLLM Attack and why it Should Scare Every SOC Analyst More Than Any CTF was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.