Telnyx Python SDK on PyPI briefly backdoored in supply‑chain attack; malicious WAV steganography used

The audio file bundled inside two versions of the Telnyx Python SDK sounded harmless. It was a ringtone. It was also how a threat actor named TeamPCP delivered a credential-stealing payload to every developer environment that pulled those packages from PyPI on March 27.

Versions 4.87.1 and 4.87.2 of the telnyx SDK went live on the Python Package Index at 03:51 UTC, stayed there for six hours and 22 minutes, and were quarantined at 10:13 UTC after Telnyx and a coordinated wave of application security firms spotted the intrusion. The telnyx package averages over one million downloads per month, roughly 30,000 per day. That attack window, short as it was, coincided with automated build pipelines firing across every time zone. Any team running an unpinned dependency or a nightly upgrade job did not choose to install the malicious package; their infrastructure chose for them.

The malicious code was injected into the file that Python loads the instant any application imports the SDK. On execution, that code reached out to a command-and-control server and retrieved what it framed as a ringtone WAV file. Researchers at Ossprey Security explained the strategy: rather than hosting a raw executable or Base64 blob on the server, where network inspection and endpoint detection tools would likely flag it, the attacker wrapped the payload inside the WAV's audio frames. Socket's team characterized the full chain as "delivery via audio steganography, in-memory execution of a data harvester, and encrypted exfiltration," with stolen data then sealed using AES-256-CBC encryption and an RSA-4096 public key before leaving the machine.

On Linux and macOS the payload hunted for SSH keys, cloud provider tokens, environment variables, and browser cookies. On Windows, TeamPCP chose persistence over immediate harvesting, planting components that would execute at every logon. Version 4.87.1 was, ironically, nonfunctional: a typo in the injected code prevented execution, which is why the attackers pushed 4.87.2 in close succession.

Any environment that ran a pip install or upgrade against the telnyx package during that six-hour window should be treated as fully compromised. The immediate step is to downgrade to telnyx version 4.87.0 and pin that version explicitly in all requirements files and lockfiles. Every credential the affected environment could have touched then needs rotation: API keys, SSH keys, cloud tokens, database passwords, and any secrets stored in environment variables. Build logs from that window should be audited for unexpected outbound connections, and if the environment shared token stores with downstream pipelines, those pipelines are suspect too.

The Telnyx incident is the fourth documented strike in a sustained TeamPCP campaign. The group backdoored Aqua Security's Trivy vulnerability scanner on March 19, earning a CVSS severity score of 9.4, then used tokens harvested from Trivy victims to deploy a self-propagating backdoor across more than 46 npm packages on March 20. LiteLLM on PyPI fell on March 24. The cryptographic fingerprints and exfiltration patterns across every incident are identical, enabling rapid attribution by researchers including teams at Aikido, Endor Labs, JFrog, SafeDep, and Datadog Security Labs.

How TeamPCP obtained Telnyx's PyPI publishing token remains formally unconfirmed. Endor Labs researchers Kiran Raj and Rachana Misal offered the most detailed hypothesis: "TeamPCP's harvester swept environment variables, .env files, and shell histories from every system that imported litellm. If any developer or CI pipeline had both litellm installed and access to the telnyx PyPI token, that token was already in TeamPCP's hands." The malicious releases also appeared without corresponding GitHub releases or tags, which Kiran Raj noted indicated the publishing credentials were compromised rather than the repository itself.

Telnyx confirmed its platform APIs and control plane were not breached. PyPI quarantined the project the same day. The harder question, for registries and their users alike, is why a stolen publishing credential was sufficient to push malicious code to a package with seven-digit monthly downloads, with no additional verification gate standing between the attacker and every pipeline that trusted the package name.