How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

362,176

Total vulnerabilities in the database

Telnyx has malicious code in PyPI versions 4.87.1 and 4.87.2 — telnyx

Embedded Malicious Code

Summary

On March 27, 2026, a threat actor used compromised PyPI credentials to publish malicious versions 4.87.1 and 4.87.2 of the telnyx Python package directly to PyPI. These versions contain credential-stealing malware and were not published through the legitimate GitHub release pipeline.

Exposure Window

| Version | Published (UTC) | Quarantined (UTC) | Exposure | |---------|-----------------|-------------------|----------| | 4.87.1 (broken) | 2026-03-27 03:51 | 2026-03-27 10:13 | 6h 22m | | 4.87.2 (functional) | 2026-03-27 04:07 | 2026-03-27 10:13 | 6h 6m |

Both versions were quarantined by PyPI at 2026-03-27 10:13 UTC.

Note: Version 4.87.1 contained a typo that prevented the malware from executing. Only 4.87.2 was fully functional.

Who Is Affected

You may be affected if:

You installed or upgraded the telnyx Python package between 03:51 UTC and 10:13 UTC on March 27, 2026
You ran pip install telnyx without pinning a version and received 4.87.1 or 4.87.2
A dependency in your project pulled in telnyx as a transitive, unpinned dependency

You are NOT affected if:

You pinned to version 4.87.0 or earlier
You installed before March 27, 2026 and did not upgrade
You built from GitHub source (malicious code was never committed to the repository)

Attack Details

Root Cause

The attacker obtained the PyPI API token and uploaded malicious packages directly to PyPI, bypassing the GitHub release pipeline entirely. No malicious commits exist in the GitHub repository.

Malicious Behavior

The malware is injected into telnyx/_client.py (74 additional lines) and executes on import telnyx:

Linux/macOS:

Spawns detached subprocess to survive parent exit
Downloads payload hidden inside WAV audio file (steganography) from C2
Harvests credentials: SSH keys, AWS/GCP/Azure creds, Kubernetes tokens, Docker configs, .env files, database credentials, crypto wallets
If Kubernetes access found, deploys privileged pods to all nodes for lateral movement
Encrypts with AES-256-CBC + RSA-4096, exfiltrates to C2

Windows:

Downloads binary hidden inside WAV file from C2
Drops as msbuild.exe in Startup folder for persistence
Executes with hidden window

Version Differences

| Version | Status | Notes | |---------|--------|-------| | 4.87.1 | Broken | Typo: Setup() instead of setup() caused NameError | | 4.87.2 | Functional | Attacker uploaded 16 minutes later to fix their own casing error; full attack chain operational |

Verified Safe Version

| Version | File | SHA-256 | |---------|------|--------| | 4.87.0 | telnyx-4.87.0-py3-none-any.whl | 5aeb8172c29ade224e6c2d166713f304596aa21e3dbfa5b6b2b028e6997f6bd2 | | 4.87.0 | telnyx-4.87.0.tar.gz | 3f093a85c313c2b779594f99fc07f453f1a7fd8785878d963688c531ff94d03a |

Recommended Actions

1. Check If You Are Affected

# Check installed version
pip show telnyx | grep Version

# Check pip cache for telnyx versions
pip cache list telnyx 2&gt;/dev/null

# Check when telnyx was installed (modification time)
ls -la $(python -c &quot;import site; print(site.getsitepackages()[0])&quot;)/telnyx* 2&gt;/dev/null

2. Remove Compromised Versions

pip uninstall telnyx

3. Rotate All Potentially Exposed Secrets

If there is any possibility that version 4.87.1 or 4.87.2 was installed in your environment, treat all accessible secrets as compromised:

SSH keys
AWS/GCP/Azure credentials
Kubernetes tokens and service accounts
Docker registry credentials
Database passwords
API keys in .env files
Telnyx API keys

4. Check for Persistence (Linux/macOS)

# Check for malicious systemd service
systemctl --user status audiomon 2&gt;/dev/null
ls -la ~/.config/audiomon/ 2&gt;/dev/null

# Check state file
ls -la /tmp/.initd_state 2&gt;/dev/null

5. Check for Persistence (Windows)

# Check Startup folder
Get-ChildItem &quot;$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe&quot;

6. Pin to Safe Version

pip install telnyx==4.87.0

Or in requirements.txt:

telnyx==4.87.0

Indicators of Compromise

Malicious Package Hashes

| File | SHA-256 | |------|--------| | telnyx-4.87.1-py3-none-any.whl | 7321caa303fe96ded0492c747d2f353c4f7d17185656fe292ab0a59e2bd0b8d9 | | telnyx-4.87.2-py3-none-any.whl | cd08115806662469bbedec4b03f8427b97c8a4b3bc1442dc18b72b4e19395fe3 |

Network

| IoC | Type | |-----|------| | 83.142.209.203 | C2 IP address | | http://83.142.209.203:8080/ringtone.wav | Payload endpoint (Linux/macOS) | | http://83.142.209.203:8080/hangup.wav | Payload endpoint (Windows) | | http://83.142.209.203:8080/raw | Persistence polling endpoint |

Filesystem

| Path | Platform | Purpose | |------|----------|--------| | ~/.config/audiomon/audiomon.py | Linux/macOS | Persistence implant | | ~/.config/systemd/user/audiomon.service | Linux | Persistence service | | /tmp/.initd_state | Linux/macOS | State tracking | | %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe | Windows | Persistence binary | | msbuild.exe.lock | Windows | 12-hour cooldown lock |

Exfiltration

Archive name: tpcp.tar.gz
HTTP header: X-Filename: tpcp.tar.gz
Encryption: AES-256-CBC + RSA-4096 OAEP

Attribution

This attack is attributed to TeamPCP with high confidence based on:

Identical RSA-4096 public key as the LiteLLM compromise (March 24, 2026)
tpcp.tar.gz archive naming convention (TeamPCP signature)
Identical AES-256-CBC + RSA OAEP encryption scheme
Same credential harvesting targets and techniques

RSA Key Hash:

PEM SHA-256: 4eceb569b4330565b93058465beab0e6d5ea09cfba8e7f29d7be1b5a2abd958a

Resources

https://github.com/team-telnyx/telnyx-python/issues/235
https://www.endorlabs.com/learn/teampcp-strikes-again-telnyx-compromised-three-days-after-litellm
https://ramimac.me/teampcp

Published: Mar 30, 2026
Updated: Mar 31, 2026
GHSA: GHSA-955r-262c-33jc
Severity: Critical
Exploit:
CISA KEV:

No technical information available.

CWEs:

CWE-506

Affected Software
References

Software	From	Fixed in
telnyx	4.87.1	4.87.2.x

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.