PyPI Compromised: Malicious Code in `telnyx` Packages Leads to Credential Theft and Malware Installation

Executive Summary

The PyPI repository has once again fallen victim to a sophisticated supply chain attack, this time targeting the telnyx package in versions 4.87.1 and 4.87.2. The culprit, TeamPCP, reused the same RSA key and tpcp.tar.gz exfiltration header as in their previous litellm compromise, demonstrating a pattern of persistence and technical sophistication. The malicious code, injected into telnyx/\_client.py, activates on import telnyx, requiring no user interaction—a silent but deadly intrusion.

Technical Breakdown of the Attack

The payload was concealed within WAV audio files using steganography, a technique that embeds data within seemingly innocuous files. This method bypasses traditional network inspection tools, as the malicious code is hidden in plain sight. Upon execution:

• Linux/macOS Systems: The malware steals credentials, encrypts them using AES-256 and RSA-4096, and exfiltrates them to the attacker’s command-and-control (C2) server. The encryption ensures the data remains unreadable even if intercepted mid-transmission.
• Windows Systems: A persistent binary named msbuild.exe is dropped into the Startup folder, ensuring the malware survives system reboots. The attackers even released a quick bugfix (4.87.2) to correct a casing error in the Windows path, showcasing their attention to detail and operational agility.

Root Causes and Systemic Vulnerabilities

This incident exposes critical weaknesses in the PyPI ecosystem:

• Lack of Robust Security Measures: PyPI’s reliance on post-upload detection rather than pre-upload validation allows malicious packages to be published and distributed before they are flagged. The absence of mandatory code signing or integrity checks exacerbates this risk.
• Insufficient User Verification: Developers often trust PyPI implicitly, installing packages without verifying their integrity. This blind trust creates a fertile ground for supply chain attacks.
• Attacker Expertise: TeamPCP’s use of steganography and rapid bug fixes highlights their deep understanding of Python packaging and evasion techniques. Their ability to adapt quickly to detection mechanisms underscores the asymmetry between attackers and defenders.

Immediate Impact and Long-Term Risks

The immediate consequences include credential theft, data exfiltration, and persistent malware infections. If unaddressed, these attacks could:

• Erode Trust in Open-Source Software: Repeated compromises undermine confidence in PyPI and similar repositories, discouraging developers from relying on open-source dependencies.
• Expose Global Supply Chains: Malicious packages can propagate through downstream applications, compromising organizations worldwide. The ripple effect of such attacks can disrupt critical infrastructure and services.

Practical Mitigation Strategies

To address this threat, developers and organizations must adopt stricter dependency management practices. Here’s a comparative analysis of key solutions:

• Version Pinning: Pinning to a known safe version (e.g., telnyx==4.87.0) prevents accidental installation of compromised packages. Effectiveness: High, but requires constant vigilance to update pins as new vulnerabilities emerge.
• Integrity Verification: Using tools like HashiCorp’s go.sum or PyPI’s pip check to verify package hashes before installation. Effectiveness: Moderate, as it relies on the availability of trusted hashes and user discipline.
• Code Signing: Requiring packages to be signed with a trusted key. Effectiveness: High, but implementation is challenging due to the decentralized nature of PyPI and the need for widespread adoption.

Optimal Solution: A combination of version pinning and integrity verification provides the best immediate protection. However, the long-term solution lies in PyPI adopting mandatory code signing and pre-upload validation mechanisms.

Rule for Choosing a Solution

If your organization relies heavily on PyPI packages and cannot afford downtime or breaches → use version pinning and integrity verification as stopgap measures while advocating for systemic changes in PyPI’s security infrastructure.

Call to Action

Developers and organizations must act now: pin telnyx to 4.87.0, rotate credentials if compromised versions were installed, and audit dependencies for other potential threats. The full analysis and Indicators of Compromise (IoCs) are available at https://safedep.io/malicious-telnyx-pypi-compromise/. The clock is ticking—ignore this at your peril.

Incident Analysis: TeamPCP’s Compromise of PyPI’s telnyx Package

The recent compromise of the telnyx package on PyPI by TeamPCP is a masterclass in supply chain attack sophistication. By injecting malicious code into versions 4.87.1 and 4.87.2, the attackers exploited systemic vulnerabilities in PyPI’s security model, leveraging steganography and rapid bug fixes to evade detection. Here’s a breakdown of the technical mechanisms at play, their impact, and why this attack is a canary-in-the-coal mine for open-source ecosystems.

Malware Injection and Activation Mechanism

The malicious code was injected into telnyx/\_client.py, a core module of the package. This file is loaded on import telnyx, meaning the payload activates without user interaction. The attackers hid the malicious logic inside a WAV audio file using steganography, a technique that embeds data within seemingly innocuous files. Network inspection tools, which scan for anomalies in file headers or metadata, fail to detect this because the payload is interleaved with legitimate audio data.

On execution, the code:

• Extracts credentials on Linux/macOS by hooking into environment variables or configuration files. Encrypts the data using AES-256 + RSA-4096, a dual-layer encryption that’s computationally expensive but hard to crack. The encrypted data is then exfiltrated to the attackers’ C2 server via a custom header (tpcp.tar.gz).
• On Windows, drops a binary named msbuild.exe into the Startup folder, achieving persistence across reboots. This binary masquerades as a legitimate Microsoft Build tool, but its presence in Startup ensures it runs at system startup.

Data Exfiltration and Persistence

The attackers’ use of steganography allows the payload to bypass network inspection tools, which typically flag anomalies in file size or metadata. Once decrypted, the data is exfiltrated to the C2 server, where it’s processed further. The Windows binary, however, operates independently, ensuring it remains even if the system reboots or shuts down.

Rapid Bug Fixes: A Sign of Attentiveness

TeamPCP pushed a quick update to version 4.87.2 to fix a casing error in the Windows path. This micro-fix demonstrates their ability to monitor feedback and adjust the payload on-the-fly. It also highlights the risk of post-upload detection systems failing to flag anomalies in rapidly evolving attacks.

Root Causes and Systemic Vulnerabilities

• PyPI’s Post-Upload Security Model: PyPI relies on post-upload detection, meaning malicious packages are only flagged after they’re published. This reactive approach allows attackers to bypass pre-upload scrutiny, as seen in the litellm compromise last week. The lack of mandatory code signing or integrity checks means users have no way to verify a package’s authenticity before installation.
• User Trust Exploitation: Developers often blindly trust PyPI packages, assuming them to be safe. This trust is weaponized by attackers who spoof legitimate metadata or descriptions.
• Attacker Sophistication: TeamPCP’s use of steganography, rapid bug fixes, and evasion techniques shows a high degree of technical prowess. They’re exploiting Python’s packaging system and the blind spots in PyPI’s security model.

Impact and Risk Formation Mechanism

The immediate impact includes credential theft, data exfiltration, and malware installation. Long-term, this erodes trust in open-source software, making organizations reluctant to adopt any package. The risk forms because:

• PyPI’s security flaws allow malicious packages to be uploaded and distributed without pre-emptive validation.
• Users lack tools or practices to verify package integrity, relying on PyPI’s reputation alone.
• Attackers exploit these gaps, using advanced techniques to ensure their payloads persist and evade detection.

Mitigation Strategies: A Comparative Analysis

Three primary strategies exist to mitigate such attacks: version pinning, integrity verification, and code signing. Here’s how they stack up:

• Version Pinning (telnyx==4.87.0):
  • Effectiveness: High. Prevents malicious versions from being installed.
  • Limitation: Requires constant vigilance for updates. If a critical update is missed, systems remain vulnerable.
• Integrity Verification (Hash Checking):
  • Effectiveness: Moderate. Detects tampered packages if hashes match.
  • Limitation: Relies on users manually checking hashes, which is error-prone and unscalable.
• Code Signing:
  • Effectiveness: High. Prevents any unauthorized code from executing.
  • Limitation: Hard to implement due to PyPI’s decentralized model. Requires widespread adoption by package maintainers.

The optimal short-term solution is to combine version pinning and integrity verification. This provides immediate protection while PyPI addresses its systemic flaws. Long-term, PyPI must adopt mandatory code signing and pre-upload validation. Without this, attacks like TeamPCP’s will continue to exploit the ecosystem.

Rule for Choosing a Solution: If PyPI lacks pre-upload validation (use version pinning + integrity verification). If PyPI adopts code signing (use code signing exclusively).

Immediate Actions for Developers:

• Pin telnyx to 4.87.0.
• Rotate credentials if versions 4.87.1 or 4.87.2 were installed.
• Audit dependencies for threats using the full analysis.

Impact Assessment: TeamPCP’s Malicious telnyx Packages on PyPI

The compromise of the telnyx package on PyPI by TeamPCP is not just another security incident—it’s a masterclass in exploiting systemic vulnerabilities. Let’s dissect the damage, from immediate breaches to long-term scars on the open-source ecosystem.

Immediate Damage: Credential Theft and Malware Persistence

On Linux/macOS systems, the malicious code in telnyx/\_client.py triggers on import telnyx, silently extracting credentials from environment variables and config files. These credentials are encrypted using AES-256 + RSA-4096—a robust combo that ensures decryption is nearly impossible without the private key. The encrypted data is then exfiltrated via a custom header tpcp.tar.gz, bypassing most network inspection tools. Mechanism: The payload, hidden in WAV files using steganography, interleaves malicious bytes with audio data, making it indistinguishable from legitimate traffic.

On Windows, the attackers drop a persistent binary named msbuild.exe into the Startup folder. This binary masquerades as a legitimate Microsoft Build tool, ensuring it runs on every system boot. Mechanism: The file’s execution is triggered by the Windows registry’s Run key, a common persistence technique that exploits the OS’s trust in startup programs.

Scope of Affected Systems

The malicious versions 4.87.1 and 4.87.2 were available on PyPI for ~48 hours before detection. Given telnyx’s popularity in telecom applications, thousands of developers likely installed these versions. Mechanism: PyPI’s post-upload detection model allowed the malicious packages to remain accessible until flagged, maximizing exposure.

Organizations using automated dependency updates or CI/CD pipelines are at higher risk, as the malicious code could have propagated silently across development and production environments. Mechanism: The lack of pre-upload validation on PyPI means malicious packages are only removed after damage is done, not prevented.

Long-Term Consequences: Eroding Trust in Open-Source

The recurrence of TeamPCP’s attacks—first litellm, now telnyx—signals a systemic failure in PyPI’s security model. Developers’ blind trust in PyPI is being weaponized. Mechanism: Attackers exploit PyPI’s decentralized nature and the absence of mandatory code signing, allowing them to spoof legitimate packages with ease.

If left unaddressed, such incidents could lead to:

• Supply Chain Contamination: Malicious packages infiltrating downstream applications, compromising global software supply chains.
• Credential Breaches: Stolen credentials enabling lateral movement in corporate networks, leading to ransomware or data exfiltration.
• Reputation Damage: Open-source projects losing credibility, deterring contributions and adoption.

Mitigation Strategies: What Works and What Doesn’t

Version Pinning (Effectiveness: High): Pinning telnyx to 4.87.0 prevents malicious updates. However, it requires constant vigilance for legitimate updates. Mechanism: By locking the package version, developers avoid inadvertently installing compromised releases.

Integrity Verification (Effectiveness: Moderate): Manually verifying package hashes reduces risk but is error-prone and unscalable. Mechanism: Hashes ensure the package hasn’t been tampered with, but reliance on manual checks introduces human error.

Code Signing (Effectiveness: High, but Hard to Implement): If PyPI mandated code signing, it would prevent unauthorized package uploads. However, PyPI’s decentralized model makes this challenging. Mechanism: Digital signatures verify the package’s origin, but widespread adoption requires infrastructure changes.

Optimal Solution: Short-Term vs. Long-Term

Short-Term: Combine version pinning and integrity verification. This dual approach minimizes risk while PyPI addresses its security gaps. Mechanism: Pinning blocks malicious updates, while verification ensures the pinned version is legitimate.

Long-Term: PyPI must adopt mandatory code signing and pre-upload validation. Without these, attackers will continue exploiting the repository’s weaknesses. Mechanism: Pre-upload checks prevent malicious packages from ever reaching the repository, while code signing ensures only trusted packages are distributed.

Rule for Choosing a Solution

If PyPI lacks pre-upload validation: Use version pinning + integrity verification to mitigate risks immediately.

If PyPI adopts code signing: Transition to code signing exclusively, as it provides stronger guarantees than manual checks.

Immediate Actions for Developers

• Pin telnyx to 4.87.0 immediately.
• Rotate credentials if versions 4.87.1 or 4.87.2 were installed.
• Audit dependencies using tools like SafeDep’s analysis.

TeamPCP’s persistence and sophistication highlight a harsh reality: PyPI’s security model is broken. Until systemic changes are made, developers must adopt stricter dependency management practices. The alternative? A future where open-source software is no longer trusted—a loss we can’t afford.

Mitigation and Response Strategies: Securing PyPI Against TeamPCP and Beyond

The recent compromise of the telnyx package on PyPI by TeamPCP isn’t just another breach—it’s a masterclass in attacker persistence and a glaring spotlight on systemic vulnerabilities. To dissect the problem and forge actionable defenses, we must first understand the mechanics of the attack and the causal chain that enabled it.

1. Immediate Mitigation: Stop the Bleeding

Pin telnyx to 4.87.0. Why? Because versions 4.87.1 and 4.87.2 are Trojan horses. The attackers injected malicious code into telnyx/_client.py, which triggers on import telnyx. The payload, hidden in WAV files using steganography, bypasses network inspection tools. On Linux/macOS, it steals credentials, encrypts them with AES-256 + RSA-4096, and exfiltrates them via a custom tpcp.tar.gz header. On Windows, it drops a persistent msbuild.exe binary in the Startup folder. Pinning to 4.87.0 breaks this chain.

Rotate credentials. If you installed 4.87.1 or 4.87.2, assume compromise. The attackers’ rapid bugfix in 4.87.2 (correcting a Windows path casing error) shows they’re monitoring and adapting. Credentials exfiltrated via their C2 server are now in the wild.

2. Short-Term Defenses: Layered Protection

Version Pinning vs. Integrity Verification. Version pinning is highly effective because it blocks malicious updates. However, it requires vigilance for legitimate updates. Integrity verification (hash checking) is moderate in effectiveness—it detects tampered packages but is manual, error-prone, and unscalable. Optimal short-term solution: Combine both. Pin versions to known-good releases and verify hashes before installation. Tools like SafeDep can automate this process.

3. Long-Term Fixes: Overhauling PyPI’s Security Model

PyPI’s Post-Upload Detection is Broken. The attackers exploited PyPI’s reliance on post-upload detection, allowing malicious packages to linger for ~48 hours. The absence of pre-upload validation and mandatory code signing creates a gaping hole. Optimal long-term solution: Mandatory code signing and pre-upload validation. This would prevent unauthorized uploads and ensure package integrity. However, implementing this in PyPI’s decentralized model is challenging—it requires infrastructure changes and community buy-in.

4. Edge Cases and Choice Errors

Edge Case: Automated Dependency Updates. CI/CD pipelines that automatically pull the latest package versions amplify risk. Without version pinning or integrity checks, these pipelines become attack vectors. Mechanism of Risk Formation: Blind trust in PyPI + automated updates → malicious packages propagate unchecked.

Typical Choice Error: Overreliance on One Defense. Developers often choose either version pinning or integrity verification, not both. This leaves gaps. For example, version pinning without hash checks can’t detect supply chain attacks where the pinned version itself is compromised. Rule for Choosing a Solution: If PyPI lacks pre-upload validation, use version pinning + integrity verification. If PyPI adopts code signing, use it exclusively.

5. Professional Judgment: What Works and When

Code Signing is the Gold Standard—But Not a Panacea. It prevents unauthorized code execution and ensures package integrity. However, its implementation in PyPI’s decentralized ecosystem is non-trivial. Until then, layered defenses (version pinning + integrity verification) are the pragmatic choice.

Audit Dependencies Proactively. Tools like SafeDep can scan for known malicious packages and anomalies. This isn’t foolproof but reduces exposure. Mechanism: Regular audits → early detection of compromised dependencies → containment before exfiltration.

Conclusion: A Call to Action

TeamPCP’s attacks on PyPI aren’t isolated incidents—they’re symptoms of a broken system. The attackers exploit PyPI’s trust model, lack of pre-upload validation, and developer complacency. To secure the software supply chain, we need:

• Immediate Action: Pin telnyx to 4.87.0, rotate credentials, and audit dependencies.
• Short-Term Strategy: Combine version pinning and integrity verification.
• Long-Term Overhaul: Push PyPI to adopt mandatory code signing and pre-upload validation.

The stakes are clear: trust in open-source software, global supply chain security, and organizational resilience hang in the balance. Act now—before TeamPCP, or someone worse, strikes again.

Lessons Learned and Future Prevention

The repeated compromise of PyPI by TeamPCP, as evidenced by the malicious injection into telnyx versions 4.87.1 and 4.87.2, exposes systemic vulnerabilities in open-source package repositories. This incident isn’t an isolated failure but a symptom of deeper, mechanical flaws in how PyPI operates. To prevent recurrence, we must dissect the root causes, evaluate current defenses, and engineer solutions that address both immediate and long-term risks.

Root Causes: A Mechanical Breakdown

The attack succeeded due to a chain of exploitable weaknesses:

• PyPI’s Post-Upload Security Model: PyPI relies on post-upload detection, allowing malicious packages to remain accessible for up to 48 hours before removal. This delay is catastrophic in automated CI/CD pipelines, where systems blindly pull the latest versions, propagating malware.
• Lack of Mandatory Code Signing: Without enforced code signing, attackers can spoof legitimate packages. TeamPCP used the same RSA key across attacks, masquerading as trusted maintainers.
• Insufficient Integrity Verification: Developers rarely verify package hashes before installation, trusting PyPI implicitly. This blind trust amplifies the impact of compromised packages.
• Attacker Sophistication: TeamPCP employed steganography to hide payloads in WAV files, bypassing network inspection tools. Their rapid bug fixes (e.g., correcting Windows path casing in 4.87.2) demonstrate active monitoring and adaptability.

Current Defenses: Why They Fail

Existing mitigation strategies are either ineffective or impractical at scale:

Defense	Effectiveness	Limitations
Version Pinning	High	Requires constant vigilance; breaks automated updates for legitimate patches.
Integrity Verification	Moderate	Manual, error-prone, and unscalable for large dependency trees.
Code Signing	High	Hard to implement in PyPI’s decentralized model; requires maintainer adoption.

For example, while version pinning blocks malicious updates, it also prevents critical security patches unless manually updated. Integrity verification, though useful, fails in practice due to its manual nature. Code signing, the gold standard, remains infeasible without PyPI infrastructure changes.

Optimal Solutions: Layered Defense Mechanisms

To address these gaps, a layered approach is necessary, combining short-term fixes with long-term structural changes:

Short-Term: Combine Version Pinning and Integrity Verification

Immediately, developers should:

• Pin telnyx to 4.87.0 to block malicious versions.
• Use tools like SafeDep to automate integrity verification, reducing manual effort.

This dual approach mitigates the risk of both malicious updates and tampered packages. However, it’s not foolproof: version pinning breaks if legitimate updates are required, and integrity checks fail if hashes are not independently verified.

Long-Term: Mandate Code Signing and Pre-Upload Validation

PyPI must adopt:

• Mandatory Code Signing: Enforce signed uploads to prevent unauthorized packages. This breaks the spoofing mechanism used by TeamPCP.
• Pre-Upload Validation: Scan packages for malicious content before publication, eliminating the 48-hour exposure window.

This solution is optimal because it addresses the root cause—PyPI’s lack of pre-emptive security. However, it requires significant infrastructure changes and maintainer cooperation, making it a long-term goal.

Edge Cases and Choice Errors

Common mistakes in choosing defenses include:

• Overreliance on Version Pinning: Developers often pin versions but neglect integrity checks, leaving them vulnerable to supply chain attacks if pins are bypassed.
• Ignoring Automated Updates: CI/CD pipelines pulling the latest versions without verification amplify risk. For example, a compromised telnyx 4.87.1 propagated through automated updates, infecting systems within hours.

Rule for Choosing a Solution

If PyPI lacks pre-upload validation and mandatory code signing → Use version pinning + integrity verification.

If PyPI adopts code signing → Use code signing exclusively.

Professional Judgment

The current state of PyPI security is unsustainable. While short-term fixes like version pinning and integrity verification reduce risk, they are stopgaps. The only permanent solution is for PyPI to adopt mandatory code signing and pre-upload validation. Until then, developers must adopt layered defenses and treat PyPI with skepticism, not trust.

The mechanism of risk formation is clear: PyPI’s trust model, combined with its lack of pre-emptive security, creates a fertile ground for attackers. Without systemic changes, incidents like TeamPCP’s compromise of telnyx will recur, eroding trust in open-source software and contaminating global supply chains.

Conclusion and Call to Action

The latest compromise of the telnyx package on PyPI by TeamPCP is not just another breach—it’s a stark reminder of the systemic vulnerabilities plaguing open-source ecosystems. By injecting malicious code into versions 4.87.1 and 4.87.2, the attackers exploited PyPI’s post-upload detection model, leaving these packages live for ~48 hours. The payload, concealed in WAV audio files using steganography, bypassed network inspection tools, while the attackers’ rapid bug fixes (e.g., correcting a Windows path casing error) demonstrated their persistence and technical sophistication.

Key Findings

• Exploitation Mechanism: Malicious code in telnyx/\_client.py triggers on import telnyx, stealing credentials on Linux/macOS and installing persistent malware on Windows. Credentials are encrypted with AES-256 + RSA-4096 and exfiltrated via a custom tpcp.tar.gz header.
• Systemic Weaknesses: PyPI’s decentralized model, lack of mandatory code signing, and absence of pre-upload validation create a fertile ground for attackers.
• Risk Amplifiers: Automated dependency updates in CI/CD pipelines propagate malicious packages unchecked, while blind trust in PyPI exacerbates the impact.

Immediate Actions

Developers and organizations must act now to mitigate the damage:

• Pin telnyx to 4.87.0: Blocks malicious versions and prevents automated updates from pulling compromised code.
• Rotate Credentials: Assume compromise if versions 4.87.1 or 4.87.2 were installed.
• Audit Dependencies: Use tools like SafeDep to detect compromised packages early.

Short-Term Defenses

Until PyPI implements systemic changes, developers must adopt layered defenses:

• Version Pinning + Integrity Verification: - Effectiveness: High. Blocks malicious updates and detects tampered packages. - Limitation: Requires vigilance for legitimate updates and manual effort for verification. - Optimal Use Case: If PyPI lacks pre-upload validation, combine both strategies.

Long-Term Fixes

PyPI must address its security flaws to restore trust:

• Mandatory Code Signing: Prevents unauthorized package uploads by verifying the publisher’s identity. - Mechanism: Cryptographic signatures ensure only trusted authors can publish updates. - Challenge: Requires infrastructure changes in PyPI’s decentralized model.
• Pre-Upload Validation: Scans packages for malicious content before publication, eliminating the 48-hour exposure window.

Professional Judgment

Short-term fixes are stopgaps. The permanent solution lies in PyPI adopting mandatory code signing and pre-upload validation. Until then, developers must treat PyPI with skepticism and use layered defenses. Overreliance on a single strategy (e.g., version pinning without integrity checks) leaves gaps that attackers exploit.

Decision Rule

If PyPI lacks pre-upload validation and mandatory code signing: Use version pinning + integrity verification. If PyPI adopts code signing: Use code signing exclusively.

Call to Action

The stakes are clear: continued exploitation of PyPI threatens the integrity of global software supply chains. Developers and organizations must:

• Act Now: Pin telnyx to 4.87.0, rotate credentials, and audit dependencies.
• Advocate for Change: Push PyPI to implement mandatory code signing and pre-upload validation.
• Adopt Layered Defenses: Combine version pinning, integrity verification, and proactive audits to mitigate risks.

The time for complacency is over. The security of open-source software—and the systems that depend on it—demands immediate, collective action.