Critical Telnyx Python SDK Backdoor on PyPI Steals Cloud Credentials

Key Takeaways

• A sophisticated supply chain attack compromised two versions (4.87.1 and 4.87.2) of the Telnyx Python SDK on PyPI, live for approximately four hours on March 27, 2026.
• The malicious packages, uploaded by the TeamPCP threat actor, silently installed a multi-stage credential harvester across Windows, Linux, and macOS systems.
• The malware used steganography to hide payloads within WAV files, collected a wide array of sensitive data including cloud credentials and SSH keys, and established persistence.
• The attack highlights a growing trend of advanced supply chain compromises, with TeamPCP previously targeting other major cybersecurity and development tools.
• Affected organizations must assume a full breach, perform extensive incident response, and rotate all compromised credentials immediately.

A critical backdoor was covertly introduced into a widely adopted Python package on the PyPI repository, enabling attackers to silently compromise systems without the knowledge of affected developers. This incident, involving the Telnyx Python SDK, represents a significant escalation in software supply chain attacks.

On March 27, 2026, a threat group identified as TeamPCP uploaded two malicious iterations of the Telnyx Python SDK to PyPI, the primary distribution platform for Python software packages. These compromised versions, 4.87.1 and 4.87.2, remained available for approximately four hours before PyPI administrators intervened and removed them.

During this brief window, any developer or automated system executing a standard package installation command could have been silently infected. The malicious code operated without errors, warnings, or any visible indications of compromise, making detection difficult for unsuspecting users.

The Telnyx package is not a niche library; it boasts approximately 750,000 monthly downloads. This broad usage implies a substantial potential impact, extending beyond direct users to encompass dependent projects, continuous integration/continuous deployment pipelines, and various services. The precision of this attack is particularly alarming: only a single file within the package was altered, with all other components remaining byte-for-byte identical to the legitimate version. The malicious code executed automatically upon the library’s import, requiring no user interaction, clicks, or configuration.

Analysts at Hexastrike identified this attack as part of a larger, rapidly evolving supply chain campaign orchestrated by TeamPCP, a group believed to be affiliated with the notorious TeamTNT threat actor. Researchers noted that TeamPCP had previously targeted prominent tools like Aqua Security’s Trivy, Checkmarx, LiteLLM, and over 46 npm packages within a mere nine-day span. Each subsequent attack demonstrated increasing sophistication, with the Telnyx compromise being the most refined version observed to date.

The attack unfolded in a three-stage process. Initially, the trojanized package activated a platform-specific loader. This loader then retrieved a hidden payload from a remote server, cunningly concealed within a WAV audio file using steganography. Finally, the decoded payload deployed a comprehensive credential harvester. This harvester surreptitiously collected SSH keys, cloud provider credentials, Kubernetes secrets, database configurations, cryptocurrency wallets, and environment variables. The stolen data was then encrypted and transmitted to an attacker-controlled server. The malware was designed to operate across all major operating systems and possessed the capability to propagate throughout entire Kubernetes clusters by deploying privileged pods on every node.

How the Infection Mechanism Was Built to Stay Hidden

The entire attack chain was initiated by a subtle modification within the _client.py file. When the Telnyx library is loaded in Python, code within this file is automatically executed.

TeamPCP inserted two function calls at the end of this file: setup() for Windows systems and FetchAudio() for Linux and macOS. Both functions performed an initial check of the operating system and would silently terminate if on the incorrect platform. To ensure stealth, all potential errors were caught and ignored using a blanket exception handler, preventing the application from crashing or generating alerts.

To obscure the true purpose of these functions, the attackers encoded all sensitive strings—including URLs, file paths, filenames, and HTTP headers—using base64. This made a quick code review less likely to reveal the malicious intent. Once decoded, the Windows path led to the download of a file named hangup.wav from a command-and-control server at 83.142.209.203:8080. This file, despite its name, was not an audio file but a valid WAV container embedding an executable binary within its audio frames through steganography. The binary was extracted, XOR-decoded, and written to the Windows Startup folder as msbuild.exe, a name deliberately chosen to mimic a legitimate Microsoft tool. It launched silently without a visible window and would execute automatically upon user login.

On Linux and macOS, the methodology differed but maintained the same level of stealth. Instead of dropping a file, the code decoded a substantial Python payload stored in a variable and executed it as a detached child process. This process persisted even after the parent application closed. It proceeded to download a second WAV file, ringtone.wav, extracted a hidden Python harvester from its audio data, and ran the script entirely in memory, avoiding any disk writes. Once the harvester completed its credential collection, the results were encrypted using AES-256-CBC, and the session key was then wrapped with a hardcoded RSA-4096 public key, ensuring only the attacker could decrypt the stolen data. The bundled information was then transmitted to the attacker’s server via an HTTP POST request, featuring the header X-Filename: tpcp.tar.gz. This unique header serves as a consistent signature across all known TeamPCP campaigns, making it a valuable network-level detection indicator.

What You Should Do

• Organizations must treat any system that installed Telnyx Python SDK versions 4.87.1 or 4.87.2 as compromised and initiate immediate incident response procedures.
• Rotate all credentials accessible from affected systems, including SSH keys, AWS, GCP, and Azure credentials, Kubernetes tokens, Docker credentials, database passwords, API keys, and any secrets stored in environment files.
• Simply uninstalling the package is insufficient to remove persistence. Manual removal steps are critical:
  • Linux: Delete ~/.config/sysmon/sysmon.py and its associated systemd service.
  • Windows: Remove msbuild.exe from the Startup folder and delete the hidden .lock file.
  • Kubernetes: Audit and remove any pods named node-setup-* in the kube-system namespace. Check every node for an unexpected systemd service named sysmon.service.
• Developers should enforce strict dependency pinning to exact versions and utilize lockfiles to prevent unexpected package updates.
• Enable two-factor authentication (2FA) on all PyPI accounts and related development platforms.
• Employ short-lived credentials wherever possible and avoid storing sensitive secrets directly in .env files on disk.
• Implement firewall rules to block all outbound connections to 83.142.209.203, checkmarx.zone, and the broader 83.142.209.0/24 subnet.

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.