LiteLLM compromised on PyPI: Tracing the March 2026 TeamPCP supply chain campaign

Key points and observations

• On March 24, 2026, two PyPI releases of LiteLLM, 1.82.7 and 1.82.8, were published with malicious code as a result of a supply chain compromise. PyPI later quarantined the project.
• Datadog Security Research's investigation determines that the LiteLLM compromise is the latest event in a five-day campaign that began with the March 19 Trivy compromise, continued with CanisterWorm on npm, and then reached Checkmarx KICS and related artifacts.
• Defenders should treat any host or CI job that installed litellm 1.82.7 or 1.82.8 as a full-credential exposure event and investigate for persistence, outbound traffic, and Kubernetes activity, not just package presence.

What happened

LiteLLM is a widely used Python library and proxy layer for talking to many LLM providers. It is important to note that this was not a fake package and not a typo-squatted name. This was a compromise of the real litellm project on PyPI as a result of an ongoing supply chain campaign that had already moved through Trivy, npm, Aqua Security's internal GitHub, and Checkmarx.

The following image provides an overview of how the whole attack is unfolding:

Before getting into the payload details, it helps to understand the timeline of events. In our analysis, the operator moved from project to project, siphoning credentials and using them to expand the campaign. Each stage reused access or tradecraft from the one before it.

March 19: Trivy is compromised

On March 19, 2026, a threat actor used compromised credentials to:

• Publish a malicious trivy v0.69.4 release
• Force-push 76 of 77 aquasecurity/trivy-action tags to malicious commits
• Replace all seven aquasecurity/setup-trivy tags.

The v0.69.4 tag triggered Trivy's standard release machinery, which then pushed the compromised build through GHCR, ECR Public, Docker Hub, deb and rpm packages, and get.trivy.dev.

The malicious trivy-action and setup-trivy commits dumped Runner.Worker memory, scraped common credential locations, encrypted the results with AES and RSA, and exfiltrated the data to scan.aquasecurtiy[.]org (a look alike domain which may avoid suspicion). If direct exfiltration failed, and a usable GitHub token was present, the malware created a public tpcp-docs repository and uploaded the stolen data there instead. This would allow the threat actors to access the exfiltrated data via this public repo.

March 19 was also not a single release-and-leave event. Additional malicious workflow injections took place into aquasecurity/tfsec, aquasecurity/traceeshark, and aquasecurity/trivy-action. By the end of the day, the campaign had already moved from one poisoned release to active reuse of a compromised identity across other repositories and workflows.

March 20 through March 22: The attacker starts spending stolen access

By March 20, the incident had already moved beyond a poisoned GitHub Action. The attacker was pushing a self-propagating npm worm across multiple publisher scopes: 28 packages in @EmilGroup, 16 in @opengov, plus @teale.io/eslint-config, @airtm/uuid-base32, and @pypestream/floating-ui-dom.

Our assessment is that this marks the first major expansion of the campaign. The worm stole npm tokens from compromised environments, resolved which packages each token could publish, bumped patch versions, fetched the original READMEs to preserve appearances, and republished the packages with the malicious payload. At that point, the attacker was automating the next compromise and broadening the campaign.

By March 22, the infrastructure behind the npm activity was also being used for something more aggressive. The same callback domain used in the npm worm was serving a Kubernetes-focused script that split victims into destructive and non-destructive paths.

The script checked timezone and locale to determine if the system was Iranian. On Iranian systems it deployed a host-provisioner-iran DaemonSet, mounted the host root filesystem, and ran a container named kamikaze that deleted the host filesystem and force-rebooted the node. On non-Iranian Kubernetes targets, it deployed host-provisioner-std, mounted / from the host, and installed persistent backdoor logic instead.

Later on March 22, the GitHub side of the campaign became more explicit. A GitHub account called Argon-DevOps-Mgt created and deleted a ghost branch on aquasecurity/trivy-plugin-aqua, then roughly seven hours later the same access was used to deface Aqua Security's internal aquasec-com GitHub organization. In total, 44 repositories were renamed, all with a tpcp-docs- prefix and the description "TeamPCP Owns Aqua Security."

March 23: the same pattern reaches Checkmarx and OpenVSX

By March 23, the campaign had moved into another vendor's release chain. The attacker(s) compromised Checkmarx/kics-github-action, Checkmarx/ast-github-action, and two OpenVSX extensions, ast-results 2.53.0 and cx-dev-assist 1.7.0.

This phase reused the same fallback pattern seen earlier in the campaign. The KICS payload used a setup.sh stealer tied to checkmarx[.]zone and fell back to creating a docs-tpcp repository with the victim's GITHUB_TOKEN if direct C2 failed.

March 23 is the clearest bridge into the LiteLLM compromise. By then, the attacker had already demonstrated a repeated pattern against GitHub Actions, package registries, and developer tooling in more than one vendor environment.

March 24: LiteLLM is published to PyPI with malicious code

litellm 1.82.7 and 1.82.8 were both released on March 24, 2026. These packages feature the same malicious payload with different execution mechanisms.

LiteLLM technical analysis

The Payload

The payload is easiest to follow as a sequence:

1. Collect secrets and credentials: The malware gathers environment variables, SSH keys, cloud credentials, Kubernetes data, Docker configs, shell history, database credentials, wallet files, and CI/CD secrets.
2. Encrypt the haul locally: It then uses a hybrid scheme for encryption: an AES-256 session key for the data, then RSA-4096 for the session key.
3. Exfiltrate it: Once encrypted on the host, the data is then sent to models.litellm[.]cloud using the header X-Filename: tpcp.tar.gz.
4. Install persistence: The payload writes ~/.config/sysmon/sysmon.py and installs a user systemd unit called sysmon.service.
5. Beacon for follow-on payloads: After this, the malware polls https://checkmarx[.]zone/raw, downloads /tmp/pglog, and executes whatever the attacker serves there next.
6. Spread in Kubernetes if it can: The payload can create privileged node-setup-* pods when it finds a usable Kubernetes service-account token. That turns a package compromise into a cluster compromise.

Version 1.82.7

litellm 1.82.7 carried an injected payload in litellm/proxy/proxy_server.py. That means the malicious logic lived in package code rather than in a one-off install hook.

A victim that installed 1.82.7, and then subsequently used the vulnerable package in their application, would execute the attackers payload.

Version 1.82.8

Version 1.82.8 is the more dangerous story. This version includes a new litellm_init.pth file inside the wheel. From the Python site documentation, executable lines in .pth files run during interpreter startup.

This means that if the package is installed, it will launch the malicious payload when the Python interpreter is started.

Responding to the incident if you're affected

Any environment with litellm 1.82.7 or 1.82.8 installed should be treated as potentially compromised, not just exposed to a bad dependency. The first question is whether the payload had an opportunity to execute. For 1.82.8, that bar is low because the malicious .pth file can run when Python starts. For 1.82.7, prioritize systems that imported the affected proxy module, especially LiteLLM proxy deployments.

Responders should focus on four things:

• Scope affected systems: Identify every host, container, CI job, and developer workstation that installed either version. Separate "package present" from "likely executed" where you can, but do not assume a system is safe if you cannot prove the payload never ran.
• Map reachable credentials: Review what the affected process could access locally and what it could fetch on demand. Prioritize cloud credentials, GitHub and package publishing tokens, CI secrets, SSH keys, Kubernetes service account tokens, .env files, and access to centralized secret stores such as AWS Secrets Manager or SSM Parameter Store.
• Rotate based on blast radius: Revoke and reissue any credential that was reachable from an affected runtime, starting with credentials that can publish code, access CI/CD, read shared secrets, or create infrastructure. If an exposed token touched a build or release pipeline, review downstream artifacts published from that environment as well.
• Hunt for follow-on activity and persistence: Look for outbound traffic to models.litellm[.]cloud, checkmarx[.]zone, related ICP or Cloudflare infrastructure, and for filesystem artifacts such as litellm_init.pth, ~/.config/sysmon/sysmon.py, ~/.config/systemd/user/sysmon.service, /tmp/pglog, and /tmp/.pg_state. In Kubernetes, review audit logs for unusual secret access, privileged pod creation, or pod names matching node-setup-*.

Do not treat reverting the LiteLLM package as a complete remediation. The recovery bar should be higher and requires removing the compromised versions, rotating reachable credentials, reviewing recent artifacts published from exposed environments, and rebuilding critical systems from known-good images and pinned dependencies.

Protecting against known malicious packages with SCFW

The Supply-Chain Firewall (SCFW) is an open-source project that transparently wraps 'pip install' and 'npm install' and automatically blocks known malicious packages such as the compromised LiteLLM ones.

We use SCFW extensively at Datadog, as it's a low-friction way to secure developer workstations against similar threats.

To try SCFW, head over to the GitHub repository.

How Datadog can help

If you're a Code Security customer, the Datadog Security Research Feed can help you easily identify if your environment is affected by this campaign, including by the latest LiteLLM compromised packages.

Datadog Code Security can also identify hosts, containers, and build environments where litellm 1.82.7 or 1.82.8 were installed. That gives you the first scope boundary.

library_name:litellm status:Open library_version:(1.82.7 OR 1.82.8)

Because the compromise primarily impacts services with floating dependencies, you may want to broaden the search to library_version:(1.82.6 OR 1.82.7 OR 1.82.8) to catch services whose data hasn’t yet been refreshed, even though 1.82.6 isn’t vulnerable on its own.

Then move to follow-on activity. Hunt for the linked domains, filesystem paths, and Kubernetes behavior across logs, workload telemetry, and cloud data. A short starting set:

Log Management:

@dns.question.name:(models.litellm[.]cloud OR checkmarx[.]zone OR *.icp0[.]io OR *aquasecurtiy[.]org OR *trycloudflare[.]com)

Note: Cloudflare Tunnels are a legitimate tool for exposing services to the internet. If your environment already uses them, narrow the query to the specific subdomains from the IoC list below instead of treating the whole service as suspicious.

source:kubernetes.audit @objectRef.resource:pods (@objectRef.name:*node-setup-* OR @requestObject.spec.containers.name:(kamikaze OR provisioner))

source:kubernetes.audit @http.method:(get OR list) @objectRef.resource:secrets @userAgent:Python-urllib*

source:cloudtrail @evt.name:(GetSecretValue OR ListSecrets OR DescribeParameters) @http.useragent:Python-urllib*

Workload Protection:

@file.path:(*litellm_init.pth OR */.config/sysmon/sysmon.py OR */.config/systemd/user/sysmon.service OR /tmp/pglog OR /tmp/.pg_state)

Conclusion

The LiteLLM incident is the latest episode in an ongoing supply-chain compromise that has involved numerous projects across millions of downloads. This is a case study in how stolen CI/CD credentials from an initial attack of one repository had cascading impact that can be turned into fresh compromises across multiple ecosystems in a matter of days.

Defenders should monitor their infrastructure for suspicious activity related to these recent compromises, and evaluate their prevention, detection, and response playbooks to determine preparedness for future attacks.

IOCs

Affected packages

Network

Filesystem and persistence

Kubernetes

Packages

Sources:

• https://research.jfrog.com/post/canister-worm/
• https://www.stepsecurity.io/blog/canisterworm-how-a-self-propagating-npm-worm-is-spreading-backdoors-across-the-ecosystem
• https://ramimac.me/trivy-teampcp
• https://github.com/aquasecurity/trivy/security/advisories/GHSA-69fq-xp46-6x23
• https://checkmarx.com/blog/checkmarx-security-update/
• https://github.com/pypa/advisory-database/blob/main/vulns/litellm/PYSEC-2026-2.yaml