TeamPCP: Cascading PyPI Attack on AI/ML Infrastructure

Key Takeaways

• A threat actor tracked as TeamPCP compromised Aqua Security’s Trivy container scanner on March 19, 2026, stealing CI/CD publishing tokens that cascaded into backdoored PyPI releases of LiteLLM (versions 1.82.7 and 1.82.8) and the Telnyx Python SDK (versions 4.87.1 and 4.87.2) — two packages central to AI/ML application development and communications infrastructure [1][2].
• The attack is distinguished by its cascading credential-reuse architecture: each compromised tool yielded authentication tokens used to compromise the next, spanning Docker Hub, npm, GitHub Actions, VS Code extensions, and PyPI across a two-week campaign [1][3].
• LiteLLM’s malicious version 1.82.8 installed a .pth startup file that causes the credential-harvesting payload to execute on every Python interpreter invocation, including after package removal via standard package managers [2][4].
• The Telnyx compromise introduced a WAV audio steganography technique previously undocumented in PyPI supply chain attacks — embedding an XOR-encrypted second-stage payload inside valid audio files to bypass content filters that inspect only source code and binaries [5].
• Affected environments should be treated as full-credential exposure events. Credentials reachable from any system where litellm==1.82.7, litellm==1.82.8, telnyx==4.87.1, or telnyx==4.87.2 were installed must be rotated regardless of whether active exfiltration is confirmed [1][5].
• As of March 25, 2026, TeamPCP announced a pivot toward active extortion through collaboration with the Vect ransomware-as-a-service group, elevating the threat posture for organizations that have not yet fully remediated [6].

Background

TeamPCP and the AI/ML Package Ecosystem

TeamPCP is a cloud-native cybercriminal group active since at least December 2025, operating public Telegram channels under handles including @Persy_PCP and @teampcp and branding their tools publicly [1][3]. This public persona — with named tools, Telegram channels, and calling-card behaviors — is more commonly associated with hacktivist and notoriety-seeking actors than with financial-motivation-first groups, though it is not without precedent in ransomware ecosystems. The group has exploited software supply chain trust relationships — specifically the implicit trust CI/CD pipelines extend to security scanning tools — as a propagation mechanism across multiple package ecosystems.

LiteLLM is a widely-used Python library that provides a unified interface for calling over one hundred large language model APIs, including those from OpenAI, Anthropic, Google, and Cohere. With approximately 95 million monthly downloads as of March 2026 [1], it sits at a critical juncture in AI application development. LiteLLM’s monthly download volume suggests broad organizational adoption, making it a likely transitive dependency in a significant fraction of AI application codebases — particularly those spanning multiple model providers. The Telnyx Python SDK provides programmatic access to Telnyx’s cloud communications platform, including voice, messaging, and networking capabilities, with approximately 742,000 monthly downloads [5].

The selection of these two packages was not accidental. Both packages are installed in CI/CD pipelines and production environments where they execute with access to the cloud credentials, API keys, and infrastructure configuration that make them attractive targets for credential theft at scale. Whether TeamPCP conducted deliberate reconnaissance before the campaign began or rapidly identified high-value targets after gaining initial access through Trivy has not been publicly confirmed; either way, the outcome reflects adversary awareness of where credentials concentrate in AI/ML development pipelines.

The Trivy Compromise as Root Cause

The proximate origin of the PyPI compromises traces to Aqua Security’s open-source container vulnerability scanner, Trivy, which was compromised beginning February 28, 2026 via theft of a GitHub Personal Access Token [1][3]. TeamPCP exploited residual access on March 19, force-pushing malicious versions 0.69.4 through 0.69.6 to 75 of Trivy’s 76 trivy-action release tags and renaming 44 Aqua Security GitHub repositories with a tpcp-docs- prefix — a calling-card behavior consistent with the group’s public persona [1][12].

Because many projects — including LiteLLM — incorporated Trivy into their GitHub Actions CI/CD pipelines as a security scanner, pulling it without a pinned version hash, the malicious Trivy releases executed within those runners and exfiltrated the PYPI_PUBLISH tokens stored as CI/CD secrets [2][4]. This is the mechanism by which TeamPCP obtained legitimate PyPI publishing credentials for LiteLLM without directly compromising LiteLLM’s maintainers or infrastructure. In a pattern that undermines assumptions about scanner trust, the security scanner itself became the attack vector.

Security Analysis

Campaign Timeline and Scope

The full campaign, which Datadog Security Labs and ReversingLabs have documented as the “TeamPCP Cascading Supply Chain Campaign,” affected multiple ecosystems across three weeks [1][3]:

Sources: Datadog Security Labs [1], Endor Labs [4], Aikido Security [5], Help Net Security [6], Arctic Wolf [10].

The npm component introduced a self-propagating capability that distinguishes it from the other affected ecosystems. TeamPCP deployed a tool they named CanisterWorm — a four-stage self-propagating worm that, given one stolen npm publishing token, enumerates all packages the token can publish and republishes malicious versions across the entire scope in under 60 seconds [3]. Its command-and-control infrastructure uses a decentralized Internet Computer Protocol (ICP) canister endpoint, chosen specifically for its resistance to conventional domain takedown actions [3].

The scale of downstream exposure was significant. Approximately 474 public repositories are confirmed to have executed malicious Trivy action code [1]. An estimated 1,750 PyPI packages were configured to automatically pull LiteLLM as a dependency [4], and TeamPCP is reported to have accumulated approximately 300 GB of stolen credentials across the campaign [6].

LiteLLM Payload Analysis

The two malicious LiteLLM versions differed meaningfully in their persistence mechanisms and therefore in the urgency of their remediation requirements. Version 1.82.7 embedded a Base64-encoded payload within proxy_server.py that executed at import time when that specific module was loaded [2][4]. This is serious but contained to environments that actively used the proxy server component.

Version 1.82.8 introduced a more persistent technique: a .pth file named litellm_init.pth installed into the Python site-packages directory [2][11][13]. Python processes .pth files during interpreter initialization, meaning the malicious payload executes on every Python invocation on the affected system — not merely when LiteLLM is imported. Critically, removing the litellm package via pip uninstall does not necessarily remove the .pth file, leaving persistence in place even after apparent remediation [4]. Any system that installed version 1.82.8 should have its entire site-packages directory inspected for the artifact litellm_init.pth regardless of the current installed version.

The payload itself operates in three stages. The first stage conducts broad credential harvesting: SSH private keys, cloud provider tokens for AWS, GCP, and Azure, Kubernetes secrets and kubeconfig files, Docker daemon configurations, shell history, database credentials, cryptocurrency wallets, and .env files containing application secrets [1][2]. The second stage performs Kubernetes lateral movement, deploying privileged pods matching the naming pattern node-setup-* to every node in any accessible cluster, granting full host filesystem access [4]. The third stage installs a persistence backdoor at ~/.config/sysmon/sysmon.py that polls checkmarx[.]zone/raw every 50 minutes for follow-on payloads [1][2]. Harvested data is encrypted with AES-256-CBC using a session key wrapped with RSA-4096 and exfiltrated to models.litellm[.]cloud [1].

Telnyx Payload and WAV Steganography

The Telnyx compromise, discovered on March 27 by Aikido Security researcher Charlie Eriksen and independently by Socket [5][14], introduced a technique not previously documented in PyPI supply chain attacks. Malicious code injected into telnyx/_client.py executes at import time and downloads a WAV audio file from 83.142.209.203:8080 — hangup.wav on Windows systems and ringtone.wav on Linux and macOS [5]. The choice of a WAV file is deliberate: many network and endpoint controls permit audio file downloads while inspecting executable content. The downloaded file is a structurally valid audio file; the malicious payload is encoded as Base64 data and embedded within the audio frames themselves, decrypted using XOR keys embedded in the file’s structure [5].

On Windows, the decoded payload drops an executable into the Startup folder using the filename msbuild.exe — mimicking a legitimate Microsoft build tool — with a 12-hour re-drop cooldown mechanism to reduce detection noise [5]. On Linux and macOS, the decoded Python script conducts credential collection targeting SSH private keys, bash history, environment variables, and .env files, exfiltrating results as tpcp.tar.gz via HTTP POST with the header X-Filename: tpcp.tar.gz to the same C2 IP address [5].

From a threat intelligence perspective, this technique indicates capability development beyond the standard PyPI supply chain attack playbook. It reflects a deliberate effort to evade signature-based scanning tools and challenges assumptions about which file types warrant behavioral analysis in security tooling. WAV steganography has been documented in other malware contexts, but its deployment in a PyPI supply chain campaign is a meaningful escalation of technique.

Ransomware Escalation

On March 25, 2026, TeamPCP publicly announced via their Telegram channels an operational partnership with the Vect ransomware-as-a-service group, a new RaaS operation [6]. At least one confirmed Vect ransomware deployment using credentials harvested through this campaign has been reported as of March 30 [6]. For organizations that have not yet fully remediated, this escalation materially elevates the threat posture from credential theft exposure to potential ransomware deployment against environments reachable from any systems where the malicious packages were installed.

Recommendations

Immediate Actions

Organizations should first determine exposure by checking whether any environment — including developer workstations, CI/CD runners, container images, and production systems — ever had litellm==1.82.7, litellm==1.82.8, telnyx==4.87.1, or telnyx==4.87.2 installed. Package manager logs, container image manifests, and dependency lock files are the primary sources for this inventory. Exposure through Trivy versions 0.69.4 through 0.69.6 should also be assessed, as these may have exfiltrated secrets from CI/CD runners independently.

Any confirmed exposure should trigger full credential rotation for all secrets accessible from the affected environment, including cloud provider credentials, API keys, database passwords, SSH keys, and CI/CD secrets such as PyPI publishing tokens and GitHub Personal Access Tokens. The .pth persistence mechanism for LiteLLM 1.82.8 means that standard package removal is insufficient: the file litellm_init.pth in site-packages must be explicitly located and removed. The persistence backdoor at ~/.config/sysmon/sysmon.py should be searched for on all affected Linux and macOS systems, and any node-setup-* pods in accessible Kubernetes clusters should be treated as attacker-controlled.

Safe versions are litellm==1.82.6 or the latest available release verified against PyPI’s official release history, and telnyx==4.87.0 [2][5]. Network traffic to models.litellm[.]cloud, checkmarx[.]zone, and 83.142.209.203 should be investigated as indicators of active compromise.

Short-Term Mitigations

CI/CD pipelines that consume open-source tooling — including security scanners — without pinning to a cryptographically verified artifact hash represent the vulnerability class that enabled this attack. Pinning GitHub Actions to a specific commit SHA rather than a mutable version tag (e.g., @v1) and pinning all downloaded binaries and packages to a known-good hash are mitigations directly applicable to the Trivy attack vector [4][9]. Organizations should audit their CI/CD pipelines for any tooling consumed without hash pinning, with particular attention to security scanning tools that execute in privileged contexts.

Private package registries with explicit allow-lists for approved packages provide meaningful protection against this class of attack. An AI/ML workload that explicitly pins all dependencies to a vetted registry significantly reduces — though does not eliminate — the risk of supply chain compromise through unauthorized packages. This control does not protect against compromise of approved packages themselves or of CI/CD tooling outside the registry’s scope, as the Trivy attack vector demonstrates. For AI/ML-specific dependencies, this allow-list approach is operationally tractable given the relatively bounded set of core packages most workloads require.

Monitoring for anomalous outbound network connections from Python processes, unexpected .pth file creation in site-packages, and suspicious pod creation in Kubernetes clusters provides detection coverage for the payload behaviors documented in this campaign. YARA rules and IOC feeds for this campaign are publicly available from JFrog, Sonatype, and Socket [4][7][8]. The SANS Internet Storm Center has also published ongoing updates tracking indicators of compromise as the campaign evolved [15].

Strategic Considerations

The TeamPCP campaign illustrates a structural vulnerability in AI/ML development: the packages that power AI workloads are consumed at extraordinary scale and velocity, often in environments with broad access to cloud credentials and infrastructure APIs. LiteLLM’s position as a universal LLM API proxy means it frequently runs in contexts that hold API keys for multiple AI providers simultaneously, Kubernetes service account tokens, and cloud provider credentials — making it an exceptionally high-value target. The evidence is consistent with deliberate targeting rather than opportunism, reflecting adversary awareness — or rapid discovery after initial access — of where credentials concentrate in AI/ML development pipelines. Whether target selection preceded or followed the initial Trivy compromise has not been publicly confirmed.

Organizations should treat AI/ML package dependencies as a distinct risk category requiring specific governance. Security policies developed for general software dependencies may underestimate the credential exposure surface of AI/ML workloads, which commonly integrate cloud services, model APIs, and infrastructure automation in ways that amplify the impact of a single package compromise. Vendor risk management processes should incorporate an assessment of an AI/ML package’s access to credential stores as part of its risk rating.

The ransomware pivot announced by TeamPCP is consistent with patterns observed in prior supply chain incidents where harvested credentials were later monetized through ransomware deployment, though systematic data on this trend is limited. The stolen credential trove reportedly estimated at approximately 300 GB [6] represents substantial leverage for follow-on campaigns well beyond the original attack window.

CSA Resource Alignment

This incident maps to threat layers and controls documented across several CSA frameworks. Within the MAESTRO framework for agentic AI threat modeling, the LiteLLM compromise demonstrates a supply chain attack against AI agent infrastructure (Layer 3: Agent Frameworks) that cascades to data exfiltration at the model interaction layer — consistent with the kind of cross-layer compromise MAESTRO’s threat model anticipates. The .pth persistence mechanism and Kubernetes lateral movement represent agent infrastructure compromise scenarios that MAESTRO’s security baseline addresses through dependency integrity requirements.

The Cloud Controls Matrix (AICM) supply chain management domain (Supply Chain Management, Transparency, and Accountability — STA) directly applies: the absence of hash pinning for CI/CD tooling represents a gap in the STA-09 (Supply Chain Risk Management) and STA-11 (Internal Information Sharing) control families. The AICM AI-specific extension addresses the elevated credential exposure surface of AI/ML workloads through its model access management controls.

CSA’s Zero Trust guidance is relevant to the lateral movement component of this attack. Kubernetes environments in which any pod can obtain cluster-admin capabilities via a compromised node, and in which CI/CD runners hold broad cloud provider credentials, contradict Zero Trust principles of least privilege and microsegmentation. The credential harvest scope documented here — encompassing SSH keys, cloud tokens, Kubernetes secrets, and database credentials simultaneously — reflects environments where Zero Trust boundaries were not enforced between different secret domains.

The STAR (Security Trust Assurance and Risk) program’s emphasis on continuous monitoring and supply chain attestation provides the assessment framework organizations should apply when evaluating their AI/ML dependency posture. Specifically, STAR Level 2 continuous monitoring requirements would mandate the kind of outbound network anomaly detection that could surface the exfiltration traffic documented in this campaign.

References

[1] Datadog Security Labs, “LiteLLM and Telnyx compromised on PyPI: Tracing the TeamPCP supply chain campaign,” securitylabs.datadoghq.com, March 2026.

[2] Sonatype, “Compromised litellm PyPI Package Delivers Multi-Stage Credential Stealer,” sonatype.com, March 24, 2026.

[3] ReversingLabs, “The TeamPCP supply chain attack evolves,” reversinglabs.com, March 27, 2026.

[4] Endor Labs, “TeamPCP Isn’t Done: Threat Actor Behind Trivy and KICS Compromises Now Hits LiteLLM,” endorlabs.com, March 24, 2026.

[5] Aikido Security (Charlie Eriksen), “Popular telnyx package compromised on PyPI by TeamPCP (CanisterWorm),” aikido.dev, March 27, 2026.

[6] Help Net Security, “TeamPCP’s attack spree slows, but threat escalates with ransomware pivot,” helpnetsecurity.com, March 30, 2026.

[7] JFrog Security Research, LiteLLM / TeamPCP campaign IOC and detection rules, jfrog.com, March 2026.

[8] Socket Security, Telnyx PyPI supply chain compromise analysis, socket.dev, March 27, 2026.

[9] Microsoft Security Blog, “Guidance for detecting, investigating, and defending against the Trivy supply chain compromise,” microsoft.com, March 24, 2026.

[10] Arctic Wolf, “TeamPCP Supply Chain Attack Campaign — Trivy, Checkmarx KICS, and LiteLLM,” arcticwolf.com, March 2026.

[11] Wiz, “Threes a Crowd: TeamPCP Trojanizes LiteLLM in Continuation of Campaign,” wiz.io, March 2026.

[12] Snyk, “How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM,” snyk.io, March 2026.

[13] LiteLLM, “Security Update: Suspected Supply Chain Incident,” docs.litellm.ai, March 2026.

[14] Telnyx, “Telnyx Python SDK: Supply Chain Security Notice,” telnyx.com, March 2026.

[15] SANS Internet Storm Center, “TeamPCP Supply Chain Campaign: Update 002,” isc.sans.edu, March 2026.