Telnyx Python SDK on PyPI was backdoored in supply chain attack that targeted Windows, macOS, and Linux

Developers who installed recent Telnyx Python SDK releases from PyPI may have pulled malicious code instead of a normal update. Security researchers and Telnyx’s own GitHub advisory say attackers published compromised telnyx versions 4.87.1 and 4.87.2 directly to PyPI on March 27, 2026 after obtaining PyPI publishing credentials.

The attack targeted Windows, macOS, and Linux systems. The malicious package executed code at import time, so simply importing telnyx in a project could trigger the payload. That made the incident especially dangerous for developers, CI pipelines, and automated build environments that trust package managers by default.

Telnyx’s GitHub security advisory says the last verified clean version is 4.87.0. PyPI quarantined the malicious releases at 10:13 UTC on March 27, which left an exposure window of just over six hours.

What happened

According to Telnyx’s incident disclosure, the attackers did not compromise the project’s GitHub source repository. Instead, they used compromised PyPI credentials to upload malicious artifacts directly to the Python Package Index, which let them bypass the normal release pipeline.

Trend Micro says the malicious code was injected into telnyx/_client.py and split across multiple locations to make visual review harder. The payload activated at module scope, which means the bad code could run during import rather than waiting for the user to call a function later.

One important detail changed the practical impact. GitHub’s advisory says 4.87.1 contained a typo that prevented the malware from executing properly, while 4.87.2 fixed that mistake and delivered the full attack chain.

Why this attack stands out

The malware used WAV audio files to hide the real payload. Trend Micro says the package downloaded structurally valid WAV files from attacker-controlled infrastructure, then decoded the embedded data at runtime. That gave the attackers a stealthier delivery method than simply stuffing the credential stealer into the package as an obvious blob of encoded text.

Researchers say the attack worked across all three major desktop and server operating systems. On Linux and macOS, the malware focused on credential theft and exfiltration. On Windows, it also attempted persistence by dropping a disguised msbuild.exe file into the Startup folder so it would run again after reboot.

Trend Micro linked the incident to a threat actor it tracks as TeamPCP. The firm says the Telnyx compromise came just days after a similar attack involving the LiteLLM package, which suggests a fast-moving campaign aimed at trusted developer tools and widely used open-source libraries.

Affected and safe versions

Package version	Status	Notes
4.87.1	Malicious, but broken	Published to PyPI with non-working malware path
4.87.2	Malicious and functional	Fully working malicious release
4.87.0	Clean	Last verified safe version

What the malware was designed to steal

Trend Micro and Telnyx say the malicious code targeted credentials and sensitive developer data. That included cloud credentials, SSH material, environment secrets, and other tokens commonly stored on workstations and build systems.

The GitHub advisory goes further and says the Linux and macOS payloads searched for AWS, GCP, Azure, Kubernetes, Docker, database, wallet, and .env secrets. It also says the harvested data was encrypted before exfiltration.

That wider targeting makes this more than a one-machine problem. A single poisoned developer laptop or CI runner can expose cloud environments, containers, internal repos, deployment pipelines, and production credentials.

What developers and organizations should do now

Anyone who installed telnyx==4.87.1 or telnyx==4.87.2 should treat the affected system as compromised. Telnyx’s advisory recommends moving back to 4.87.0 and starting incident response steps immediately.

Security teams should isolate affected hosts, rotate exposed credentials, review build logs from the exposure window, and inspect whether those package versions were pulled by direct or transitive dependencies. A downgrade alone is not enough if the malicious package already ran.

Teams should also look for suspicious outbound requests tied to the attacker infrastructure and unexpected msbuild.exe files in Windows Startup locations. That can help identify machines where the payload moved beyond initial execution.

Quick response checklist

• Pin telnyx to 4.87.0
• Search environments for 4.87.1 and 4.87.2
• Isolate any machine that imported the compromised package
• Rotate API keys, cloud credentials, SSH keys, and tokens
• Review CI/CD logs from March 27, 2026
• Check Windows Startup folders for suspicious msbuild.exe
• Hunt for outbound traffic to the reported attacker infrastructure

FAQ