PyPI Supply Chain Attack Targets Telnyx SDK Users

What Happened in the Telnyx PyPI Attack?

Attackers operating under the TeamPCP campaign uploaded two trojanised versions of the Telnyx Python SDK to PyPI, the Python Package Index. The malicious packages targeted developer environments running Windows, macOS, and Linux — meaning no operating system provided a safe harbour. Telnyx is a widely used communications platform whose SDK is integrated into production systems by thousands of development teams globally. The attack follows a pattern that is becoming disturbingly familiar: take a legitimate, trusted package; modify it to include malicious code; push it to a public registry; and wait for developers to pull it into their projects during routine dependency updates. Because the package carries a recognised name and passes a surface-level inspection, automated dependency managers install it without challenge. The incident was reported by SecurityWeek and adds Telnyx to a growing list of reputable vendors whose package identities have been weaponised against their own users.

What Is the TeamPCP Campaign and Why Does It Matter?

TeamPCP is not a one-off. It is an active, expanding supply chain attack campaign targeting PyPI-hosted packages. The fact that attackers chose to imitate the Telnyx SDK specifically — a package used in production communications infrastructure — tells you something about the maturity of their targeting. They are not picking obscure libraries. They are targeting dependencies that sit inside live systems handling real business data. PyPI processes billions of package downloads each month. According to the Python Software Foundation, PyPI hosts over 500,000 projects. Even a fractional compromise rate across that ecosystem produces a substantial blast radius. The TeamPCP actors understand this arithmetic well. What makes this campaign particularly difficult to defend against is the trust model that underpins open-source development. Developers do not audit every package they install. They rely on registries, version histories, and community reputation. Attackers exploit exactly that trust — inserting malicious code into the gap between what a package claims to be and what it actually does.

How Does a Trojanised PyPI Package Actually Compromise a System?

When a developer runs a standard pip install command or updates a dependency, the package manager fetches the latest version from PyPI and executes any installation scripts it contains. This is the attack surface. Malicious packages routinely abuse setup.py or pyproject.toml hooks to run arbitrary code at install time — before the developer has reviewed a single line of the package contents. Once executed, typical payloads in supply chain attacks of this type include:

• Credential harvesting: extracting API keys, tokens, and environment variables from the developer's machine or CI/CD pipeline
• Backdoor installation: dropping persistent remote access tools that survive the removal of the offending package
• Data exfiltration: sending sensitive configuration data, source code fragments, or internal hostnames to attacker-controlled infrastructure
• Lateral movement staging: using the compromised developer environment as a foothold into connected cloud accounts, internal networks, or production systems

Why Developer Environments Are High-Value Targets

A compromised developer workstation is not just a compromised workstation. It is a compromised set of credentials, a compromised build pipeline, and potentially a compromised production deployment. Developers routinely hold access to source code repositories, cloud provider consoles, container registries, and internal APIs. In many organisations, a single developer's environment contains enough access to pivot directly into production infrastructure. CI/CD pipelines compound this risk further. When a trojanised package is pulled into an automated build process, the malicious code executes in an environment that may have even broader permissions than the individual developer's machine — deploying credentials, signing keys, and infrastructure access that attackers can harvest at scale. This is why supply chain attacks on package registries have grown in frequency. Attackers gain access not to one target, but to every organisation downstream of the compromised package. The Telnyx SDK attack is a direct expression of that logic. For organisations using Hadrian for attack surface management, this class of risk is increasingly visible at the perimeter — particularly where public-facing services depend on third-party packages with unverified integrity. Understanding what sits in your dependency tree is now as important as knowing what sits on your network.

What Should UK and NZ Development Teams Do Right Now?

If your teams use the Telnyx Python SDK, audit your installed versions immediately and compare package hashes against the verified releases published in Telnyx's official changelog and GitHub repository. Do not assume the version number is sufficient confirmation of integrity — the malicious packages in the TeamPCP campaign used version identifiers designed to appear legitimate. Beyond the immediate Telnyx-specific check, this incident should prompt a broader review of your software supply chain hygiene:

• Pin dependency versions explicitly and use lock files to prevent automatic updates pulling in unreviewed changes
• Implement hash verification for all package installations in your build pipelines — pip supports --require-hashes for this purpose
• Deploy a private package mirror or proxy such as Nexus or Artifactory, and whitelist approved packages rather than pulling directly from public registries
• Scan dependencies continuously with software composition analysis (SCA) tooling — not just at initial install, but on every build
• Review CI/CD pipeline permissions and apply least-privilege principles — a build agent should not hold production deployment credentials unless the deployment step has been explicitly verified
• Treat third-party supply chain risk as an ongoing assessment, not a point-in-time check. Platforms like Panorays can help organisations track supplier-side risk continuously, including exposure from third parties who themselves rely on open-source components

The Broader Pattern: Open Source Registries Under Sustained Attack

PyPI is not the only registry under pressure. npm, RubyGems, NuGet, and Maven Central have all seen similar campaigns over the past two years. According to Sonatype's 2023 State of the Software Supply Chain report, supply chain attacks increased by 742% year-on-year between 2019 and 2022. The trajectory has not reversed. The TeamPCP campaign fits squarely into this pattern. Attackers have identified package registries as a force multiplier: one successful upload can compromise hundreds or thousands of downstream organisations simultaneously, all of whom implicitly trusted the registry to serve them clean code. For security teams, this creates a monitoring challenge that traditional endpoint detection alone does not solve. By the time a trojanised package has executed its install-time payload, the damage to credentials and environment variables may already be done — before any file is written to disk in a form that a conventional antivirus signature would catch. This is precisely where anti-data exfiltration tooling becomes relevant. BlackFog, for instance, is designed to detect and block unauthorised data leaving the device regardless of the mechanism — including the kind of silent outbound calls that install-time malware makes to attacker infrastructure. Meanwhile, for organisations operating managed detection and response through Sophos MDR, the telemetry generated by a compromised developer environment — unexpected outbound connections, anomalous process behaviour during package installation, credential access patterns — provides the signals needed to catch an active intrusion before it escalates.

What This Means for Your Security Posture

The Telnyx PyPI incident is a useful forcing function. Supply chain risk has been a theoretical priority for many organisations for several years. It is no longer theoretical — it is weekly news. The organisations that fare best are those that have moved beyond perimeter thinking. They know what third-party code runs in their environments, they verify its integrity continuously, and they have detection coverage that catches the behavioural indicators of compromise even when signature-based tools miss the initial payload. If your organisation has not conducted a software supply chain audit in the past twelve months, now is the time. If your development pipelines pull packages from public registries without hash verification or SCA scanning, that gap needs to close. And if your security team does not have visibility into outbound data flows from developer workstations and build servers, you are operating blind to a class of attack that is actively growing. Kyanite Blue Labs will continue to track the TeamPCP campaign as it develops. Organisations seeking to understand their exposure — whether through attack surface assessment with Hadrian, third-party risk monitoring with Panorays, or data exfiltration protection with BlackFog — can contact our team for a direct conversation.

Frequently Asked Questions