TeamPCP Backdoors PyPI ‘telnyx’ Package, Hides Payloads Inside WAV Audio Files

By Ash K
TeamPCP Backdoors PyPI ‘telnyx’ Package, Hides Payloads Inside WAV Audio Files

The Python package ecosystem has been hit by another supply-chain attack after threat actors linked to TeamPCP backdoored the telnyx package on PyPI, turning a widely used communications SDK into a credential-stealing malware delivery vehicle. According to the incident details, the malicious releases were telnyx 4.87.1 and 4.87.2, both pushed in the early hours of March 27, while the last known safe release is 4.87.0. The malware executes as soon as a user runs import telnyx, with no setup prompts or installer warnings.

What makes this campaign particularly notable is not just the package compromise itself, but how the payload is delivered. Rather than downloading an obvious executable or script, TeamPCP used WAV audio files as delivery containers. The malicious code was hidden inside structurally valid audio frame data using base64 encoding and XOR obfuscation, a technique that allows the files to pass MIME-type checks and blend in with traffic that many security tools would treat as benign.

The broader context matters. The report ties the Telnyx compromise to TeamPCP’s larger March campaign, which has already touched Trivy, CanisterWorm activity across npm, Checkmarx, and LiteLLM. In the Telnyx case, the attackers are believed to have used a stolen PyPI token to publish malicious wheels directly, bypassing the project’s normal automated release pipeline. The repository itself reportedly showed no signs of source-code compromise, and the suspicious packages had no matching GitHub tags or workflow runs. PyPI metadata also reportedly showed an upload-client mismatch, suggesting a manual push using stolen credentials rather than a legitimate CI/CD publish.

Software supply chain and malicious package compromise concept
The Telnyx compromise shows how attackers are evolving from simple malicious packages to stealthier, layered payload delivery inside trusted developer ecosystems.

The malware behavior differs by operating system. On Windows, the malicious setup() routine downloads hangup.wav from 83[.]142[.]209[.]203:8080, extracts a PE payload from the WAV frame data, writes it to the Startup folder as msbuild.exe, and launches it silently for persistence. A hidden lock file is also created to keep the malware from re-dropping too frequently. On Linux and macOS, the package uses a separate FetchAudio() path that decodes a hardcoded base64 blob, launches it in a detached subprocess, downloads ringtone.wav, extracts another-stage payload from the audio frames, encrypts stolen data with AES, wraps the key with RSA-4096, and exfiltrates the result back to the same server using the HTTP header X-Filename: tpcp.tar.gz.

One small but interesting detail is that version 4.87.1 appears to have contained a typo involving Setup() versus setup(), which reportedly caused a runtime error and prevented the attack chain from fully executing. Version 4.87.2 corrected that bug. Even so, both versions should be treated as malicious because they represent compromised releases pushed with attacker-controlled credentials.

The WAV-based delivery method is what most sharply raises the bar for defenders. The extraction routine is technically simple, reading audio frames, base64-decoding them, using the first eight bytes as an XOR key, and decrypting the rest into the actual payload. But operationally, it is clever. For a communications SDK, downloading an audio file does not look inherently suspicious. That means the traffic can evade basic filters and static checks that are tuned to spot binary payloads, shell scripts, or encoded PowerShell. TeamPCP reportedly tested this trick in a Kubernetes wiper only days earlier, then moved it into a PyPI supply-chain attack at production scale.

The attribution to TeamPCP is also stronger than in many early-stage package attacks. The report says the Telnyx malware reused the same RSA-4096 public key seen in the LiteLLM compromise, the same X-Filename: tpcp.tar.gz exfiltration header, and the same encryption flow built around AES-256-CBC and RSA-wrapped session keys. The only major change was the move from a domain-based command-and-control setup to a raw IP address and the newer WAV-based delivery format.

Indicators published with the incident include the malicious versions 4.87.1 and 4.87.2, SHA256 values for both packages, the C2 server 83[.]142[.]209[.]203:8080, the two WAV payload URLs, the exfiltration header, the Windows persistence path, and the injection point in src/telnyx/_client.py. Defenders are advised to downgrade immediately to telnyx==4.87.0, remove the malicious versions from environments and private mirrors, rebuild compromised systems from known-good images, and rotate all secrets reachable from affected machines. Detection guidance includes blocking the C2 IP, alerting on the X-Filename: tpcp.tar.gz header, monitoring for Python child-process launches via sys.executable, and flagging suspicious msbuild.exe execution from the Startup folder.

The larger lesson is that TeamPCP’s campaign is no longer just about one poisoned package at a time. It is about credential chaining. Each compromised tool leaks new tokens and secrets, which are then used to poison additional packages, SDKs, or pipelines in the next wave. In that model, every victim can become a supplier of access for the next victim. The Telnyx incident shows how quickly those stolen credentials can be turned into stealthy, high-trust malware delivery through software components developers routinely import without a second thought.

Reference Links and Sources

  • Pasted user-provided incident analysis on the PyPI telnyx compromise and TeamPCP tradecraft
Ash K
Ash K
Ashton is a seasoned Cybersecurity Professional with over 25 years of experience in Cybersecurity Research, Cybersecurity Incident response, Products and Security Solutions architecture.