Backdoored Telnyx PyPI package delivered WAV-hidden malware in TeamPCP supply-chain incident

Photo by protect.computer on protect.computer

What happened

Multiple security teams reported a supply-chain compromise of the official Telnyx Python SDK package on PyPI. Malicious versions 4.87.1 and 4.87.2 were published and, according to incident reports, executed attacker code automatically during package import.

Researchers say the payload chain downloaded WAV files from attacker infrastructure, extracted hidden code (steganography + decryption routine), and harvested secrets including credentials, tokens, keys, and environment variables.

Why this matters

This is high impact because the package is widely used in developer and CI/CD environments. If a malicious dependency executes at import time, compromise can spread from a single build host to cloud credentials, production secrets, and downstream systems.

For affected teams, this should be treated as a credential exposure and environment compromise event, not just a dependency hygiene issue.

How to check if you’re affected

Potentially affected systems/services

Affected versions: Python environments that installed telnyx version 4.87.1 or 4.87.2.
CI/CD runners, developer workstations, and build agents where those versions were imported/executed.
Any secrets accessible from those systems (cloud API tokens, SSH keys, package registry credentials, CI variables).

Concrete verification steps (15–45 minute triage)

Identify impacted installs immediately
- Search lockfiles, dependency manifests, artifact caches, and build logs for telnyx==4.87.1 or telnyx==4.87.2.
- Prioritize environments that executed jobs during the exposure window.
Check execution telemetry on affected hosts
- Review process/network logs for unexpected outbound fetches of WAV artifacts and suspicious Python child-process activity.
- Inspect startup/persistence locations on Windows hosts if those versions were imported.
Contain and remediate dependency risk
- Remove compromised package versions from caches and mirrors.
- Pin to a known-clean release (researchers cite 4.87.0 as clean in this incident).
Rotate potentially exposed secrets
- Immediately rotate cloud credentials, SSH keys, CI tokens, and any API keys present on impacted systems.
- Revoke and re-issue secrets with least privilege and shorter lifetimes where possible.
Treat high-confidence exposures as incident response
- Isolate and reimage high-risk hosts where malicious versions executed.
- Hunt for secondary persistence and lateral movement before returning systems to production.

Immediate defensive actions

Blocklist known malicious package versions in internal artifact controls.
Enforce dependency pinning + provenance checks for build pipelines.
Add detections for suspicious dependency runtime behavior (network egress from import hooks, steganography-like fetch/decode chains).

Sources

Bottom line

If your environment touched Telnyx 4.87.1 or 4.87.2, assume secrets may be exposed and respond like a real breach: contain, rotate credentials, and verify no persistence remains.