A sophisticated supply chain attack has compromised the Telnyx Python SDK, a widely used library downloaded by hundreds of thousands of developers monthly. Threat actor TeamPCP successfully injected malicious code into versions 4.87.1 and 4.87.2 of the Telnyx Python SDK, uploading them to the Python Package Index (PyPI) on March 27, 2026. These compromised versions remained accessible for approximately four hours before PyPI took action to quarantine them. The attack’s stealthy nature meant that any developer or system installing these versions during that window could have been infected without any visible indication of compromise.
The compromised Telnyx package is not an obscure tool; its broad adoption means the potential impact of this attack is significant, affecting numerous projects, development pipelines, and services reliant on it. The attackers demonstrated a high degree of precision, altering only a single file within the package while leaving the rest byte-for-byte identical to the legitimate version. This allowed the malicious code to execute automatically the moment any application imported the library, requiring no user interaction or additional configuration.
According to Hexastrike analysts, this incident is part of a larger, aggressive supply chain campaign by TeamPCP, an actor linked to the previously known TeamTNT group. This same group has been remarkably active, having previously targeted Trivy from Aqua Security, Checkmarx, LiteLLM, and over 46 npm packages within a nine-day period. The Telnyx compromise represents the most advanced iteration of their tactics observed by researchers.
The infection mechanism employed a three-stage structure. Initially, the trojanized Telnyx Python SDK package triggered a platform-specific loader. This loader, in turn, fetched a concealed payload from a remote server, which was hidden within a WAV audio file through steganography. The final stage involved the decoded payload deploying a comprehensive credential harvester designed to extract sensitive information. This harvester systematically collected SSH keys, cloud provider credentials, Kubernetes secrets, database configurations, cryptocurrency wallet details, and environment files. The stolen data was then encrypted and exfiltrated to a server controlled by the attackers. Notably, the malware was designed to operate across major operating systems and could potentially propagate throughout Kubernetes clusters by deploying privileged pods on affected nodes.
How the Infection Mechanism Was Built to Stay Hidden
The critical entry point for this sophisticated attack was a carefully crafted modification within the `_client.py` file of the Telnyx package. Python’s standard procedure for loading libraries involves automatically executing code contained within specific files, including `_client.py`. The threat actor added two discreet function calls to the end of this file: `setup()` for Windows systems and `FetchAudio()` for Linux and macOS. These functions employed an initial operating system check and would silently terminate if executed on an incompatible platform, ensuring a low profile.
To further obscure their malicious activities, the attackers implemented a robust error handling mechanism. Every potential error encountered during the execution of the malicious code was meticulously caught and silently ignored through a blanket exception handler. This prevented any application crashes or error alerts, allowing the infection to proceed undetected.
Sensitive strings, including URLs, file paths, and headers, were systematically encoded using base64. This obfuscation technique made it difficult for a superficial code review to immediately reveal the attacker’s objectives. Upon decoding, the Windows path instructed the system to download a file named `hangup.wav` from a command-and-control (C2) server located at `83.142.209.203:8080`. This file, masquerading as an audio file, actually contained a binary executable hidden within its WAV container using steganography.
The extracted binary was then decoded using an XOR key and subsequently written to the Windows Startup folder under the filename `msbuild.exe`. This choice of name was deliberate, mimicking a legitimate Microsoft tool to evade suspicion. The malicious executable would launch automatically upon user login without displaying any visible window, ensuring persistent, low-profile execution.
On Linux and macOS systems, the infection method differed but remained equally stealthy. Instead of dropping a file, the code decoded a substantial Python payload stored within a variable and executed it within a detached child process. This process was designed to remain active even after the parent application terminated. It proceeded to download a second WAV file, `ringtone.wav`, extract a Python harvester from the audio data, and run it entirely in memory, thus avoiding any file-based artifacts on disk. Once the credential harvesting was complete, the collected data was encrypted using AES-256-CBC, and the session key was protected using a hardcoded RSA-4096 public key, ensuring only the attacker could decrypt the stolen information. The encrypted payload was then bundled into a file and transmitted to the attacker’s server via an HTTP POST request, marked by the specific header `X-Filename: tpcp.tar.gz`, a consistent indicator across known TeamPCP campaigns that aids in network-level detection.
Organizations that may have installed versions 4.87.1 or 4.87.2 of the Telnyx Python SDK should immediately initiate their incident response protocols, treating such installations as confirmed breaches. A critical next step involves rotating all credentials accessible from affected systems, including SSH keys, cloud provider credentials for AWS, GCP, and Azure, Kubernetes tokens, Docker credentials, database passwords, API keys, and any secrets stored in environment files. It is important to note that simply uninstalling the compromised package will not remove the persistent backdoor.
On Linux systems, manual removal of the file `~/.config/sysmon/sysmon.py` and its associated systemd service is necessary. For Windows, the `msbuild.exe` file in the Startup folder and any associated hidden `.lock` files must be deleted. In Kubernetes environments, administrators should audit and remove any pods named `node-setup-*` within the `kube-system` namespace and verify that no unexpected systemd services named `sysmon.service` are present on any nodes. As a preventative measure, developers are strongly advised to pin all dependencies to exact versions, utilize lockfiles, enable two-factor authentication on their PyPI accounts, employ short-lived credentials whenever feasible, avoid storing secrets in `.env` files directly on disk, and implement firewall rules to block outbound connections to `83.142.209.203`, `checkmarx.zone`, and the broader `83.142.209.0/24` subnet.