The official Telnyx Python SDK on PyPI was compromised this morning as part of an escalating, weeks-long supply chain campaign orchestrated by the threat actor group TeamPCP.
Malicious versions 4.87.1 and 4.87.2 of the telnyx package were uploaded to PyPI at 03:51 UTC on March 27, 2026, with the payload executing silently at import time on both Windows and Linux/macOS systems.
Organizations using these versions should treat affected environments as fully compromised and immediately rotate all exposed credentials.
TeamPCP Supply Chain Attack
The Telnyx compromise is not an isolated event it is the latest link in a credential-chaining supply chain campaign that TeamPCP has been executing since March 19, 2026.
The group’s operating pattern is precise and repeatable: compromise a trusted security or developer tool, steal the CI/CD credentials it exposes, use those credentials to poison the next target in the chain, harvest whatever secrets the new environment holds, and repeat.
The campaign timeline reads as follows:
March 19: Aqua Security’s open-source vulnerability scanner Trivy was backdoored, assigned CVE-2026-33634 (CVSS 9.4). TeamPCP force-pushed malicious binaries to 75 of 77 trivy-action tags and 7 setup-trivy tags, harvesting CI/CD secrets including npm tokens, Docker Hub credentials, and PyPI publishing tokens from every pipeline running Trivy without version pinning. By end of day, 44 Aqua Security GitHub repositories were renamed with the prefix tpcp-docs-.
March 20: Using stolen npm tokens from Trivy victims, TeamPCP deployed the CanisterWorm backdoor across 46+ npm packages. The worm automated token-to-compromise: given one stolen npm token, it enumerated all publishable packages, bumped versions, and published malicious releases across entire scopes in under 60 seconds.
March 22: Researchers observed TeamPCP deploying WAV steganography to deliver payloads in a Kubernetes wiper variant. A malware payload was embedded inside .wav audio files — disguising binary data as valid audio frames — marking the debut of a technique that would reappear five days later in the Telnyx compromise.
March 23: Checkmarx’s kics-github-action and ast-github-action GitHub Actions were compromised, along with two OpenVSX extensions (cx-dev-assist 1.7.0 and ast-results 2.53.0). The attacker hijacked 35 tags between 12:58 and 16:50 UTC using a new C2 domain, checkmarx[.]zone, impersonating Checkmarx’s brand. Malicious code was removed approximately three hours later.
March 24: LiteLLM versions 1.82.7 and 1.82.8 were published to PyPI using credentials stolen from LiteLLM’s CI/CD pipeline, which itself ran unpinned Trivy. LiteLLM serves roughly 95 million downloads per month and is widely deployed as a centralized LLM gateway with access to credentials for OpenAI, Anthropic, AWS Bedrock, GCP Vertex AI, and more. PyPI quarantined the packages within approximately three hours. The C2 was models[.]litellm[.]cloud.
March 27 (today): Telnyx — with 742,000 downloads over the past month — becomes the latest victim.
The Telnyx Payload: Import-Time Execution
According to Akidio advisory, the malicious injection in the Telnyx package resides in telnyx/_client.py and runs at import time. There is no install hook to disable, no postinstall script to block the malware executes the moment a developer or application calls import telnyx. The attack forks into two execution paths depending on the host operating system.
On Windows, the payload downloads hangup.wav from the attacker’s C2 at 83[.]142[.]209[.]203:8080. The audio file’s frame data contains a base64-encoded, XOR-obfuscated executable.
After decoding, the dropper writes the executable to %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe, ensuring it executes silently on every system login. A hidden .lock file enforces a 12-hour re-drop cooldown to reduce detection surface.
On Linux and macOS, a complete second-stage Python script is hardcoded as a base64 blob in _client.py at line 459. This script fetches ringtone.wav from the same C2, decodes a third-stage collector script from the WAV frames using the same XOR technique, and executes it via sys.executable piped to stdin.
The collected output is encrypted with AES-256-CBC; the session key is wrapped with an attacker-held RSA-4096 public key (OAEP), ensuring only the attacker can decrypt the exfiltrated data. The exfil bundle is transmitted via HTTP POST with the header X-Filename: tpcp.tar.gz.
The WAV Steganography Technique
The payload delivery mechanism deserves particular attention. Rather than fetching a raw binary or a Python script — both of which raise content-filtering and URL-inspection alarms — TeamPCP delivers its payloads disguised as .wav audio files. The files are structurally valid audio and pass MIME-type checks. The malicious content is concealed within the audio frame data using the following decode 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))])
The first 8 bytes of the decoded frame data serve as the XOR key; the remainder is the obfuscated payload. Content-based security filters inspecting the file as audio will find nothing anomalous.
This technique was first observed in TeamPCP’s Kubernetes wiper on March 22. Its reuse in the Telnyx package just five days later — carrying both the Windows dropper and the Linux infostealer confirms that TeamPCP has standardized it as part of their toolkit.
Indicators of Compromise
CategoryIndicatorMalicious packagetelnyx==4.87.1 (SHA256: 7321caa303fe96ded0492c747d2f353c4f7d17185656fe292ab0a59e2bd0b8d9)Malicious packagetelnyx==4.87.2 (SHA256: cd08115806662469bbedec4b03f8427b97c8a4b3bc1442dc18b72b4e19395fe3)C2 server83[.]142[.]209[.]203:8080Windows payload URLhxxp://83[.]142[.]209[.]203:8080/hangup.wavLinux/macOS payload URLhxxp://83[.]142[.]209[.]203:8080/ringtone.wavExfil endpointhxxp://83[.]142[.]209[.]203:8080/ (POST)Exfil headerX-Filename: tpcp.tar.gzWindows persistence path%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exeWindows lock file%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe.lock
Mitigation Steps
Organizations that installed telnyx==4.87.1 or telnyx==4.87.2 should take the following actions without delay:
Remove the malicious versions — Downgrade to telnyx==4.87.0 and pin the version explicitly in all dependency files.
Treat the environment as compromised — Rotate all API keys, database credentials, SSH keys, cloud provider tokens, and any other secrets accessible from the affected machine or CI/CD pipeline.
Windows-specific — Check for msbuild.exe in %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ and delete it along with any accompanying .lock file.
Network monitoring — Block and monitor for all outbound HTTP traffic to 83[.]142[.]209[.]203:8080.
Audit CI/CD pipelines — Review whether any build pipelines running the affected Telnyx versions also had access to credentials for other packages or platforms, as TeamPCP’s documented behavior is to use each compromise to enable the next.
Given the FBI’s assessment following the LiteLLM compromise that “a surge in breach disclosures, follow-on intrusions, and extortion attempts” is expected in the coming weeks, organizations integrating Python-based telecommunications or AI infrastructure packages should urgently audit their dependency trees and enforce version pinning across all environments.
Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.
The post Telnyx PyPI Package With 742,000 downloads Compromised in TeamPCP Supply Chain Attack appeared first on Cyber Security News.
