# Supply Chain Threat Actor TeamPCP Targets Python Ecosystem With Poisoned Telnyx Package


A sophisticated threat group known as TeamPCP has expanded its supply chain attack campaign by compromising the widely-used telnyx Python package, injecting malicious code designed to harvest sensitive credentials from developers and systems that install the affected versions. The campaign represents an escalation in the group's targeting strategy, which has already claimed several high-profile infrastructure tools as victims.


## The Threat


On March 27, 2026, two malicious versions of the telnyx package—versions 4.87.1 and 4.87.2—were published to the Python Package Index (PyPI), the primary distribution platform for Python libraries. The packages were engineered to steal sensitive authentication credentials and configuration data from systems where they were installed. What distinguishes this particular attack is the use of obfuscation: the malicious payload was concealed within a .WAV audio file embedded within the package, a technique designed to evade automated security scanning and human code review.


The telnyx package provides Python developers with easy integration to the Telnyx communications platform, which handles SMS messaging, voice calls, and other telecommunications services. Given its role in production systems across numerous organizations, the compromise posed significant risk to any developer or organization that updated to the poisoned versions during the window of availability.


## Background and Context


TeamPCP is not a new threat actor. The group has demonstrated sophisticated capabilities and operational security practices across multiple high-impact campaigns. Prior to targeting the telnyx package, TeamPCP was linked to the compromise of critical open-source security tools, including Trivy (a container vulnerability scanner), KICS (an infrastructure-as-code security tool), and litellm (a language model integration library).


This pattern of attacks reveals a deliberate strategy: TeamPCP targets widely-adopted infrastructure and developer tools—projects with substantial download volumes and deep integration into enterprise development workflows. By poisoning these upstream dependencies, the group gains access to organizations through their own development pipelines, effectively bypassing many external security controls.


The telnyx compromise fits neatly into this established pattern. The package benefits from significant adoption among developers building communication-heavy applications, particularly in the startup and fintech sectors where Telnyx's services are common infrastructure choices.


## Technical Details


### The Attack Mechanism


Rather than embedding obfuscated Python code directly into the package source, TeamPCP employed a stealthier approach: the malicious code was hidden within a .WAV file, a common audio format. This technique offers several tactical advantages. First, automated security scanners that focus on code analysis often give less scrutiny to binary or media files included in Python packages. Second, during casual code review, security researchers may overlook non-code artifacts, especially media files that appear to serve legitimate purposes (such as sample audio for telecommunications testing). Third, extracting and executing code from a .WAV file creates an additional obfuscation layer that makes static analysis more difficult.


The malicious payload itself functioned as a credential stealer, designed to extract authentication tokens, API keys, and configuration information from the infected system. Depending on the scope of the infection, this could have compromised:


  • API credentials for Telnyx and other integrated services
  • Authentication tokens and session data
  • Database connection strings and passwords
  • Cloud provider credentials (AWS keys, Azure tokens, etc.)
  • Encryption keys or other cryptographic material

  • Once exfiltrated, this information would provide attackers with direct access to the victim organization's infrastructure, communication systems, and potentially downstream applications and services.


    ## Scope and Impact


    PyPI security responses depend heavily on the speed at which the community identifies and reports malicious packages. In this instance, the poisoned versions remained available for a critical period before being flagged and removed. The exact duration of availability and the number of installations during that window—key metrics for assessing true impact—determined the scope of the compromise.


    Organizations most at risk from this specific attack include:


  • Fintech and payment companies that rely on Telnyx for SMS-based authentication
  • Healthcare platforms using Telnyx for patient communication
  • SaaS companies offering communication features to their own customers
  • Startups in the messaging space that depend on Telnyx infrastructure
  • Development teams that frequently update dependencies

  • Even organizations using the legitimate telnyx package may face residual risk if their systems updated automatically or if developers pulled the poisoned versions into local development environments and generated compiled artifacts.


    ## Response and Remediation


    ### Immediate Actions


    Organizations should:


  • Audit telnyx installations across all development and production environments to identify any systems using versions 4.87.1 or 4.87.2
  • Revoke credentials immediately if the telnyx package was installed on systems with access to sensitive data or infrastructure
  • Restore to a known-good version (4.87.0 or earlier) and conduct a fresh installation
  • Check authentication logs for any suspicious activity coinciding with the dates the poisoned packages were available

  • ### Longer-Term Considerations


  • Review dependency management practices to ensure automatic updates don't install potentially malicious code without review
  • Implement cryptographic signing verification for critical dependencies
  • Consider using private package mirrors that cache and vet packages before making them available to development teams
  • Maintain detailed inventory of package versions across all environments to support rapid impact assessment

  • ## Technical Recommendations


    For Package Users:


  • Pin major dependency versions in production environments rather than accepting automatic minor/patch updates
  • Use a Software Composition Analysis (SCA) tool to monitor open-source dependencies for known vulnerabilities and suspicious activity
  • Implement code review processes that specifically examine package contents, not just application code
  • Verify package integrity using cryptographic hashes when available

  • For the Open Source Community:


  • PyPI should implement stronger verification requirements for package publishers, particularly those publishing to widely-used namespaces
  • Automated malware scanning tools should be enhanced to detect code hidden in non-code files and executed dynamically
  • The Python ecosystem should accelerate adoption of digital package signing standards

  • ## HackWire Analysis


    The TeamPCP campaign represents a maturing threat landscape where sophisticated attackers understand that directly compromising end-user systems is far less efficient than poisoning the supply chain. By targeting shared dependencies, a single successful compromise can provide access to dozens or hundreds of downstream organizations with minimal additional effort.


    What makes this campaign particularly notable is the refinement of obfuscation techniques. The use of .WAV files as a vehicle for malicious code suggests that threat actors have analyzed defensive workflows and specifically engineered attacks to evade them. This adaptation indicates that supply chain security defenses are having some effect—enough that attackers feel compelled to improve their tradecraft.


    Organizations cannot rely solely on external security vendors to protect against these threats. The telnyx compromise, like its predecessors, ultimately required human vigilance and rapid community response. For companies building on open-source infrastructure, the lesson is clear: dependency management is now a critical security function, not merely an operational convenience.