TeamPCP Strikes Again: Malicious `litellm` Packages (1.82.7/1.82.8)
Just when we thought the supply chain chaos was settling down, TeamPCP is back at it. Following their compromises of Trivy and KICS, it looks like they used the access gained from the Trivy CI/CD breach to push malicious versions of the popular Python library litellm.
According to reports from Endor Labs and JFrog, versions 1.82.7 and 1.82.8 are currently weaponized. This isn't just a typo squat or a dependency confusion attack; the actual maintainers' pipeline (or Trivy's influence on it) appears to have been leveraged.
The Payload Breakdown: These versions contain a nasty cocktail:
- Credential Harvester: Scanning for environment variables and config files.
- K8s Lateral Movement Toolkit: Specific tools designed to pivot within Kubernetes clusters.
- Persistent Backdoor: Maintaining access for further C2 operations.
Immediate Action Items:
If you are using litellm, audit your environments immediately. You can check your installed version using:
pip show litellm
If you are running versions 1.82.7 or 1.82.8, treat the host as compromised. Rotate all credentials and investigate Kubernetes logs for anomalous activity. For a quick Python check in your automation scripts:
import pkg_resources
CURRENT_VERSION = pkg_resources.get_distribution("litellm").version
MALICIOUS_VERSIONS = ["1.82.7", "1.82.8"]
if CURRENT_VERSION in MALICIOUS_VERSIONS:
print(f"CRITICAL: Malicious version {CURRENT_VERSION} detected.")
else:
print(f"Safe: Version {CURRENT_VERSION} is clear.")
Given that litellm is widely used in LLM integrations, the blast radius here could be massive. How is everyone handling dependency pinning for high-risk libraries like this in their CI/CD pipelines right now? Are we still just trusting pip install?
We're seeing a lot of teams blindly trusting the 'verified publisher' badge on PyPI, but as this attack shows, if the upstream CI/CD (Trivy in this case) is owned, the badge means nothing.
We've moved to enforcing --require-hashes in our requirements.txt files for production builds. It's a pain to update, but it prevents this exact scenario where a new version is swapped out maliciously.
The Kubernetes lateral movement toolkit part is the scariest bit. Most devs toss litellm into a container without thinking about the permissions that pod has.
If that pod had a service account token with any decent permissions, they likely owned the cluster. I'm running this KQL query across our logs to see if we had any downloads of those specific versions:
ContainerImageRepository == 'pypi'
| where PackageName == 'litellm'
| where PackageVersion in ('1.82.7', '1.82.8')
I'm curious about the detection methods for the credential harvester. Does anyone have IOCs for the C2 domains or the specific HTTP requests it's making? Standard EDR might flag the K8s toolkit, but if the harvester is just reading ~/.aws/credentials, it might look like normal app behavior to a baseline monitor.
Valid point, Hannah. Until the C2 domains are fully published, querying SIEM logs for the specific installation commands is the fastest way to find infected hosts. If you're using Sentinel, try this KQL query to catch the install attempts:
DeviceProcessEvents
| where ProcessCommandLine contains 'litellm' and (ProcessCommandLine contains '1.82.7' or ProcessCommandLine contains '1.82.8')
This should reveal the scope of the compromise quickly.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access