Critical Telnyx PyPI Package Compromised in TeamPCP Supply Chain Attack
Key Takeaways The official Telnyx Python SDK on PyPI was compromised by the TeamPCP threat group. Malicious versions 4.87.1 and 4.87.2 of the telnyx package contain a payload that executes silently...
Key Takeaways
- The official Telnyx Python SDK on PyPI was compromised by the TeamPCP threat group.
- Malicious versions 4.87.1 and 4.87.2 of the
telnyxpackage contain a payload that executes silently upon import. - This incident is part of a broader, weeks-long supply chain campaign by TeamPCP targeting developer tools and critical infrastructure.
- Organizations using the compromised versions must immediately treat affected environments as fully compromised and rotate all credentials.
The official Python SDK for Telnyx on PyPI has fallen victim to a sophisticated supply chain attack, becoming the latest target in an ongoing campaign orchestrated by the threat actor group known as TeamPCP. This compromise marks a significant escalation in a series of attacks that have plagued the software supply chain for weeks.
Table Of Content
Malicious versions 4.87.1 and 4.87.2 of the telnyx package were uploaded to PyPI on March 27, 2026, at 03:51 UTC. These versions harbor a stealthy payload designed to execute silently at the moment the package is imported, affecting both Windows and Linux/macOS systems.
Any organization that has incorporated these compromised versions into their systems should consider their environments fully breached and take immediate action to revoke and replace all exposed credentials.
TeamPCP’s Calculated Supply Chain Offensive
The Telnyx incident is not an isolated event but rather a calculated step in a credential-chaining supply chain campaign that TeamPCP initiated on March 19, 2026. The group’s modus operandi is characterized by precision and repeatability: infiltrate a trusted security or developer tool, pilfer the CI/CD credentials it exposes, leverage those credentials to infect the next target, extract any secrets found in the new environment, and then repeat the cycle.
The timeline of this aggressive campaign reveals a clear pattern of escalation:
- March 19: Aqua Security’s open-source vulnerability scanner, Trivy, was backdoored, leading to the assignment of CVE-2026-33634 with a CVSS score of 9.4. TeamPCP force-pushed malicious binaries to 75 out of 77
trivy-actiontags and 7setup-trivytags. This allowed them to harvest CI/CD secrets, including npm tokens, Docker Hub credentials, and PyPI publishing tokens, from every pipeline that executed Trivy without version pinning. By the end of the day, 44 Aqua Security GitHub repositories had been renamed with the prefixtpcp-docs-. - March 20: Utilizing the npm tokens stolen from Trivy victims, TeamPCP deployed the CanisterWorm backdoor across more than 46 npm packages. This worm automated the process of token-to-compromise: given a single stolen npm token, it could enumerate all publishable packages, bump their versions, and publish malicious releases across entire scopes in under 60 seconds.
- March 22: Researchers observed TeamPCP employing WAV steganography to deliver payloads within a Kubernetes wiper variant. A malware payload was ingeniously embedded inside
.wavaudio files, masking binary data as legitimate audio frames. This marked the debut of a novel technique that would resurface five days later in the Telnyx compromise. - March 23: Checkmarx’s
kics-github-actionandast-github-actionGitHub Actions were compromised, alongside two OpenVSX extensions (cx-dev-assist 1.7.0andast-results 2.53.0). The attackers hijacked 35 tags between 12:58 and 16:50 UTC, using a new C2 domain,checkmarx[.]zone, to impersonate Checkmarx’s brand. The malicious code was removed approximately three hours later. - March 24: LiteLLM versions 1.82.7 and 1.82.8 were published to PyPI. The credentials used for this action were stolen from LiteLLM’s CI/CD pipeline, which itself had run an unpinned version of Trivy. LiteLLM, which sees approximately 95 million downloads per month, is widely deployed as a centralized LLM gateway, often holding credentials for services like OpenAI, Anthropic, AWS Bedrock, and GCP Vertex AI. PyPI swiftly quarantined these packages within roughly three hours. The C2 server for this incident was identified as
models[.]litellm[.]cloud. - March 27 (today): Telnyx, boasting 742,000 downloads over the past month, became the latest organization to fall victim to this concerted campaign.
The Telnyx Payload: Execution at Import Time
As detailed in an advisory by Akido, the malicious code injected into the Telnyx package resides within the telnyx/_client.py file and activates upon import. This design means there are no conventional installation hooks to disable or postinstall scripts to block; the malware executes the moment a developer or application calls import telnyx. The attack diverges into two distinct execution paths, depending on the host operating system.
On Windows systems, the payload initiates a download of a file named hangup.wav from the attacker’s C2 server located at 83[.]142[.]209[.]203:8080. This audio file’s frame data contains a base64-encoded, XOR-obfuscated executable.
Following decoding, the dropper writes the executable to %APPDATA%MicrosoftWindowsStart MenuProgramsStartupmsbuild.exe, thereby ensuring its silent execution with every system login. To reduce its detection footprint, a hidden .lock file enforces a 12-hour cooldown period before the re-dropping of the executable.
For Linux and macOS environments, a complete second-stage Python script is hardcoded as a base64 blob within _client.py at line 459. This script retrieves ringtone.wav from the identical C2 server. It then decodes a third-stage collector script embedded within the WAV frames using the same XOR technique and executes it by piping it to sys.executable via stdin.
The collected output is subsequently encrypted using AES-256-CBC. The session key for this encryption is then wrapped with an RSA-4096 public key held by the attacker (OAEP), guaranteeing that only the attacker can decrypt the exfiltrated data. This exfiltration bundle is transmitted via HTTP POST with the header X-Filename: tpcp.tar.gz.
The WAV Steganography Technique
The payload delivery mechanism employed by TeamPCP warrants particular scrutiny. Instead of directly fetching a raw binary or a Python script—both of which are more likely to trigger content-filtering and URL-inspection alarms—TeamPCP delivers its malicious payloads disguised as .wav audio files. These files are structurally valid audio and successfully bypass typical MIME-type checks. The nefarious content is cleverly hidden within the audio frame data, decoded using the following logic:
with wave.open(wf, 'rb') as w:
b = base64.b64decode(w.readframes(w.getnframes()))
s, m = b[:8], b[8:]
payload = bytes([m[i] ^ s[i % len(s)] for i in range(len(m))])
In this scheme, the initial eight bytes of the decoded frame data serve as the XOR key, with the remaining data comprising the obfuscated payload. Security filters that inspect the file purely as audio will find no anomalies.
This sophisticated technique was first observed in TeamPCP’s Kubernetes wiper on March 22. Its subsequent reuse in the Telnyx package just five days later—delivering both the Windows dropper and the Linux infostealer—confirms that WAV steganography has been standardized as a core component of TeamPCP’s toolkit.
Indicators of Compromise
| Category | Indicator |
|---|---|
| Malicious package | telnyx==4.87.1 (SHA256: 7321caa303fe96ded0492c747d2f353c4f7d17185656fe292ab0a59e2bd0b8d9) |
| Malicious package | telnyx==4.87.2 (SHA256: cd08115806662469bbedec4b03f8427b97c8a4b3bc1442dc18b72b4e19395fe3) |
| C2 server | 83[.]142[.]209[.]203:8080 |
| Windows payload URL | hxxp://83[.]142[.]209[.]203:8080/hangup.wav |
| Linux/macOS payload URL | hxxp://83[.]142[.]209[.]203:8080/ringtone.wav |
| Exfil endpoint | hxxp://83[.]142[.]209[.]203:8080/ (POST) |
| Exfil header | X-Filename: tpcp.tar.gz |
| Windows persistence path | %APPDATA%MicrosoftWindowsStart MenuProgramsStartupmsbuild.exe |
| Windows lock file | %APPDATA%MicrosoftWindowsStart MenuProgramsStartupmsbuild.exe.lock |
What You Should Do
Organizations that have installed telnyx==4.87.1 or telnyx==4.87.2 must take immediate and decisive action:
- Remove Malicious Versions: Downgrade your
telnyxpackage to version4.87.0and explicitly pin this version in all your dependency management files to prevent automatic updates to compromised versions. - Assume Full Compromise: Treat any environment where these malicious versions were installed as fully compromised. Immediately rotate all sensitive credentials, including API keys, database credentials, SSH keys, and cloud provider tokens, that were accessible from the affected machine or CI/CD pipeline.
- Windows-Specific Remediation: On Windows systems, check for the presence of
msbuild.exein the%APPDATA%MicrosoftWindowsStart MenuProgramsStartupdirectory. Delete this executable and any accompanying.lockfile found in the same location. - Network Monitoring and Blocking: Implement network rules to block all outbound HTTP traffic to the identified C2 server:
83[.]142[.]209[.]203:8080. Actively monitor network logs for any attempts to connect to this IP address. - Audit CI/CD Pipelines: Conduct a thorough audit of all CI/CD pipelines to determine if any build processes running the affected Telnyx versions also had access to credentials for other packages or platforms. Given TeamPCP’s documented behavior of leveraging each compromise to facilitate the next, this step is crucial for identifying and mitigating further potential breaches.
In light of the FBI’s assessment following the LiteLLM compromise—warning of “a surge in breach disclosures, follow-on intrusions, and extortion attempts” in the coming weeks—organizations integrating Python-based telecommunications or AI infrastructure packages should urgently audit their dependency trees and enforce strict version pinning across all development and production environments.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.