Telnyx Python SDK on PyPI, using a multi‑stage WAV steganography payload to steal credentials across Windows, macOS, and Linux systems.
The backdoor lives in telnyx/_client.py and is triggered at module scope, so simply importing telnyx is enough to execute the payload before any application code runs.
The rogue releases remained available for roughly 6.5 hours before PyPI quarantined them at around 10:13 UTC, according to the project’s security notice.
Any environment that installed or imported these versions should be treated as fully compromised, with Telnyx urging users to revert to the last known clean build, version 4.87.0.
On March 27, 2026, attackers published two malicious Telnyx SDK versions, 4.87.1 and 4.87.2, directly to PyPI without matching commits in the official GitHub repository.
Attribution to the TeamPCP threat actor is backed by strong technical overlap with the earlier LiteLLM supply‑chain incident.
Researchers note an identical RSA‑4096 public key, the same tpcp.tar.gz campaign identifier, a shared X-Filename: tpcp.tar.gz exfiltration header, and a reused OpenSSL‑based chain that combines random data, AES‑256‑CBC, and RSA‑OAEP before sending archives to the command‑and‑control server.
These shared elements clearly point to the same toolchain, confirming that Telnyx is part of a broader, ongoing TeamPCP campaign.
PyPI Telnyx Python SDK
Unlike the earlier LiteLLM backdoor, which inserted a single contiguous malicious block, the Telnyx payload is split across multiple regions of _ client.py to avoid casual inspection.
Analysts observed three main components: a small Base64 decode helper function _d() hidden among legitimate imports, a 4,428‑character Base64 blob containing the Linux/macOS orchestrator, and a Windows‑specific execution path appended after the SDK’s normal class definitions.
Both the Windows and Unix‑like paths are invoked at import time, ensuring automatic execution on any supported platform.
All sensitive strings in the Windows branch are obfuscated and only revealed at runtime through the _d() Base64 wrapper.
Decoded values include the Startup folder path, the msbuild.exe filename used for persistence, and the HTTP command‑and‑control URL, further complicating static analysis.
In contrast, LiteLLM’s malicious block included many plaintext strings inside a single Base64 payload, making it easier for defenders to spot suspicious infrastructure indicators.
The most significant technical shift is the move away from embedding the credential stealer directly in the package code to hiding it inside WAV audio files downloaded at runtime.
When the backdoor runs, it retrieves a seemingly valid WAV file from the attacker‑controlled server and parses raw audio frames using Python standard wave module, then Base64‑decodes the data.
The decoded bytes are split so that the first eight bytes become an XOR key and the remainder form the XOR‑encrypted payload; iterating over the blob with a rotating eight‑byte key reconstructs the cleartext stealer.
These WAV files are structurally valid media objects, pass MIME‑type checks, bypass basic file‑extension filters, and contain no easily searchable strings, significantly improving evasion over the inline Base64 approach seen in LiteLLM.
Researchers previously observed TeamPCP experimenting with WAV steganography in a Kubernetes wiper script (kamikaze.sh), and the Telnyx incident shows the technique moving from prototype to production in under a week.
Cross‑platform credential theft
Where LiteLLM focused solely on Linux, the Telnyx backdoor adds dedicated Windows support while maintaining Linux and macOS capability.
On Windows, the malware downloads hangup.wav from 83[.]142[.]209[.]203:8080, extracts a PE executable via the XOR steganography routine, and drops it as msbuild.exe under %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ to achieve user‑level boot persistence.
The binary is launched using the CREATE_NO_WINDOW flag to avoid visible windows, and an anti‑replay mechanism checks a hidden msbuild.exe.lock file, skipping re‑execution if the lock has been modified within the last 12 hours to reduce noise and detection.
On Linux and macOS, the Base64‑encoded payload is decoded and executed as a detached background process using subprocess.Popen with a new session and suppressed I/O.
This process then downloads ringtone.wav from the same C&C IP, extracts the credential stealer using the same XOR‑based routine, and runs it, feeding harvested credentials and secrets into the familiar TeamPCP exfiltration pipeline: archive data into tpcp.tar.gz, encrypt with AES‑256‑CBC and RSA‑4096, and send via HTTP POST with the custom X-Filename: tpcp.tar.gz header.
Targets include SSH keys, environment variables, cloud credentials and other high‑value secrets in CI/CD, developer, and production environments.
Telnyx also marks a departure from the domain‑based HTTPS infrastructure used in earlier TeamPCP stages such as LiteLLM.
Instead of hiding behind domains like models.litellm.cloud and checkmarx.zone over HTTPS, the Telnyx payload talks directly to 83[.]142[.]209[.]203:8080 over plaintext HTTP for both WAV downloads and exfiltrated archives.
Researchers speculate that prior C2 domains may have been reported or disrupted, forcing the actor to fall back to raw IP addressing at the cost of increased network visibility.
This shift opens up new detection opportunities for defenders monitoring egress traffic. Suspicious indicators include WAV file downloads from non‑media IPs on port 8080, outbound HTTP POSTs carrying tpcp.tar.gz archives with an X-Filename: tpcp.tar.gz header, and anomalous msbuild.exe binaries or hidden .lock files in Windows Startup directories.
Network security teams can hunt for these signatures across proxies, firewalls, and IDS/IPS logs, while EDR tools can be tuned to flag unusual process chains involving Python importing Telnyx followed by shell or msbuild.exe activity.
Organizations that installed Telnyx versions 4.87.1 or 4.87.2 should immediately downgrade to Telnyx 4.87.0 and assume that affected systems are fully exposed.
Incident response teams should rotate all credentials accessible from those environments, including API tokens, SSH keys, and CI/CD secrets, and perform full compromise assessments on developer workstations, build servers, and production hosts where the package was imported.
Defenders should also search for the presence of msbuild.exe in user Startup folders, msbuild.exe.lock files with hidden attributes, and any evidence of unusual WAV downloads from 83[.]142[.]209[.]203:8080.
Longer‑term, teams are strongly advised to pin all PyPI dependencies by version and hash, enforce reproducible builds, and restrict who can publish to official package repositories using hardware‑backed authentication and scoped tokens.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
