CVE-2026-33634: Supply Chain Compromise and Malicious Code Execution in Telnyx Python SDK

CVE-2026-33634 represents a critical supply chain compromise affecting the official Telnyx Python SDK (telnyx) distributed via the Python Package Index (PyPI). The threat actor, identified as TeamPCP, successfully authenticated to PyPI using compromised developer credentials and directly published two malicious package versions: 4.87.1 and 4.87.2. This direct upload mechanism completely bypassed the project's established GitHub-based CI/CD pipeline, which is normally managed by Stainless.

The isolation of the PyPI registry from the source code repository resulted in a discrepancy where the GitHub repository remained uncompromised. No corresponding tags, releases, or commits exist in the public version control history for versions 4.87.1 or 4.87.2. Developers and automated dependency management systems pulling the telnyx package directly from PyPI received the malicious artifact automatically, provided their version pinning permitted the update.

The injected payload is categorized as Embedded Malicious Code (CWE-506). Approximately 74 lines of unauthorized code were appended to the core client module located at telnyx/_client.py. Because this module is fundamentally required for the SDK's operation, the malicious execution chain is initiated instantaneously whenever a downstream application executes the import telnyx statement. No further application interaction or specific API calls are required to trigger the exploit.

The malicious injection operates as an immediate execution hook during the Python module initialization phase. Upon execution of import telnyx, the injected code evaluates the underlying operating system environment using platform.system(). This evaluation dictates the distinct execution paths and payloads deployed against Windows versus Unix-like systems. Both paths utilize a shared technique of WAV audio steganography to obscure the secondary payloads and evade network-level signature detection.

The primary steganographic mechanism involves downloading a seemingly benign .wav file from the threat actor's command and control (C2) infrastructure at 83.142.209.203:8080. The malware reads the data frames of the audio file, bypassing standard audio headers. The payload is obfuscated using an XOR cipher, a technique designed to bypass static analysis engines that inspect downloaded binaries.

The extraction routine leverages the first 8 bytes of the hidden data chunk as the XOR decryption key. The Python script reads this prefix, iterates over the subsequent byte array, and applies the XOR operation to reconstruct the original executable or script. Once the payload is successfully reassembled in memory, it is written to the local disk and executed.

When the compromised SDK is imported within a Windows environment, the malware invokes a designated setup() function. This function is explicitly engineered to establish persistent access and execute a compiled binary payload. The code dynamically constructs a file path pointing to the current user's Startup folder: %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe. Masquerading as the legitimate Microsoft Build Engine (msbuild.exe) reduces immediate suspicion during manual system inspection.

To prevent redundant executions and excessive resource consumption that might alert the user, the malware implements a locking mechanism. It attempts to create or verify the existence of an msbuild.exe.lock file in the same directory. The script checks the timestamp of this lock file; if the lock file exists and was modified within the preceding 12 hours, the execution halts. If the conditions are met, the script proceeds to download hangup.wav from the C2 server.

Following the XOR steganography extraction, the resulting executable is written to the msbuild.exe path. The Python script then executes the binary using the subprocess module. Crucially, it passes the CREATE_NO_WINDOW creation flag (0x08000000) to the Windows API. This flag ensures the binary runs entirely in the background without spawning a visible console window, allowing the persistence mechanism and subsequent C2 communications to operate silently.

On Linux and macOS systems, the environment check routes execution to the FetchAudio() function. The infection chain on Unix-like systems prioritizes immediate, high-value data extraction over long-term binary execution. The script initiates an HTTP GET request to download ringtone.wav from the identical C2 infrastructure used in the Windows attack path.

The XOR extraction sequence reconstructs a secondary Python script rather than a compiled executable. This secondary script operates as a highly specialized credential stealer. It initiates an aggressive file system traversal, specifically targeting user home directories for sensitive configuration files. Primary targets include .env files, .aws/credentials, SSH keys, and shell history files (.bash_history, .zshrc).

The exfiltration phase employs robust cryptographic protocols. Collected data is consolidated and encrypted using the AES-256-CBC algorithm. The symmetric AES key is subsequently encrypted using a hardcoded RSA-4096 public key embedded within the stealer. This hybrid encryption schema ensures that network defenders intercepting the traffic cannot decrypt the payload without the corresponding RSA private key held by TeamPCP.

The final encrypted blob is packaged and transmitted to the C2 server via an HTTP POST request. To bypass standard web application firewalls and format expectations, the threat actor utilizes a custom HTTP header: X-Filename: tpcp.tar.gz. The presence of this specific header, combined with the RSA-4096 key signature, matches the operational profile observed in the prior compromise of the LiteLLM package, confirming TeamPCP attribution.

The impact of CVE-2026-33634 is total system compromise scoped to the privileges of the user executing the Python process. On Windows, the attacker gains persistent arbitrary code execution. On Linux and macOS, the attacker successfully extracts authentication tokens, cloud provider credentials, and environment variables. These stolen credentials facilitate immediate lateral movement, data exfiltration from adjacent cloud environments, and further supply chain attacks if the victim holds repository write access.

Because the vulnerability exists exclusively within the PyPI distribution and not the source repository, the remediation required administrative intervention at the package registry level rather than a code-level patch. The standard GitHub repository for Telnyx remained untainted. Telnyx security personnel mitigated the issue by revoking the compromised publishing credentials, deleting versions 4.87.1 and 4.87.2 from PyPI, and designating version 4.87.0 as the latest stable release.

No residual vulnerability remains in the underlying SDK codebase. However, environments that cached the malicious package versions locally or within internal artifact registries (e.g., JFrog Artifactory, Sonatype Nexus) remain susceptible until the specific hashes are explicitly banned and purged. Developers must explicitly downgrade to version 4.87.0 to eliminate the threat.