When Trusted Packages Turn Hostile: Cascading Supply Chain Attacks

TeamPCP compromised the telnyx Python package on PyPI on March 27, 2026, pushing versions 4.87.1 and 4.87.2 with a credential stealer hidden in a WAV file. Endor Labs assessed the publishing token had been harvested three days earlier from the compromised litellm package. One stolen credential set bought the next package.

Updated September 2026: on August 27, 2026 the Australian Federal Police arrested two men in Perth on 14 combined cybercrime charges over the TeamPCP campaign, and the U.S. Attorney’s Office for the Northern District of California announced a federal grand jury indictment of one of them. The defensive guidance below is unchanged.

The compromise was reported on the telnyx repository and analyzed by Aikido, Endor Labs, JFrog, SafeDep, Socket, StepSecurity and Snyk within hours. The attacker was not a random actor: TeamPCP is the same group that had already backdoored litellm, Aqua Security’s trivy, and Checkmarx’s KICS earlier that month.

This is a cascading supply chain attack. One compromised package gives attackers the keys to compromise the next. And the pattern has implications that go well beyond PyPI.

The Campaign at a Glance

Date (2026)	Target	Malicious artifact	Reach
Feb 28	Trivy (Aqua Security)	Release tags v0.27.0 through v0.69.1 deleted	Container scanner in CI
Mar 19	Trivy, again	v0.69.4 tag hijacked	Same
Mar 20-22	npm, then Docker Hub	45+ packages republished by a self-propagating worm	Stolen CI tokens
Mar 23	KICS (Checkmarx), OpenVSX	GitHub Action and extension marketplace	IaC scanner in CI
Mar 24	litellm on PyPI	1.82.7 and 1.82.8; 1.82.6 was the last clean release	95M downloads/month
Mar 27	telnyx on PyPI	4.87.1 and 4.87.2, live 6 hours 22 minutes	742,000 downloads in the prior 30 days

Sources: Endor Labs for the wave dates and LiteLLM figures, StepSecurity for the telnyx download count and payload analysis, The Hacker News for the exposure window, and Datadog Security Labs for the indicators.

Datadog’s account of the campaign is one sentence long:

Each stage reused access or tradecraft from the one before it.

— Datadog Security Labs, LiteLLM and Telnyx compromised on PyPI

Endor Labs put the same mechanic more bluntly: “Each compromised environment yields credentials that unlock the next target.”

Typosquats vs. Trusted Package Compromise

Most supply chain attacks we’ve discussed on this blog - including the ClawHavoc campaign that hit the AI skill ecosystem in January - rely on some form of deception at the point of installation. Typosquats, name confusion, fake descriptions. The attacker publishes something new and hopes you install it by mistake.

TeamPCP’s approach is fundamentally different. They aren’t publishing new packages. They’re compromising existing, legitimate packages that developers already trust and depend on.

When you install telnyx@4.87.1, you’re not making a mistake. You’re updating a package you’ve used before, from a publisher you’ve verified before, through a registry you trust. The version number increments normally. The package name is correct. The publisher account is the real one. Every signal you’d normally check says “this is safe.”

This is what makes trusted package compromise so dangerous: it defeats the human review layer entirely.

How the Cascade Works

TeamPCP’s campaign followed a clear pattern across multiple targets.

Stage 1: Initial compromise. The group gained access to publishing credentials for security tooling that sits inside CI, starting with Trivy on February 28. Compromising a scanner is not incidental - a scanner runs in pipelines that hold credentials for everything else.

Stage 2: Credential harvesting. The malicious versions contained a data harvester that swept environment variables, .env files, cloud credentials, Kubernetes tokens and shell histories from every machine that imported the package. Datadog recorded AES-256 session keys wrapped with RSA-4096 before exfiltration, and persistence via litellm_init.pth and a systemd unit.

Stage 3: Lateral movement to new packages. Endor Labs assessed that the most likely vector for the Telnyx compromise was credentials harvested during the litellm attack three days earlier. If any developer or CI pipeline had both litellm installed and access to Telnyx’s PyPI publishing token, that token was already in TeamPCP’s hands.

Stage 4: Repeat. Each new compromised package harvests more credentials, expanding the attack surface for the next compromise. Between March 20 and March 22 the group spent stolen npm access across 45+ packages via a self-propagating worm.

Figure: the campaign is not six independent incidents. Each wave is funded by credentials taken in the previous one - which is why the telnyx compromise needed no new initial access.

The target selection is deliberate: tools with elevated access to automated pipelines, where a single compromised dependency can touch thousands of downstream environments. Two of the six waves hit vulnerability scanners.

The Payload: Steganography and Platform-Specific Persistence

TeamPCP’s malware delivery is technically sophisticated. The malicious Telnyx versions injected code into a single file - src/telnyx/_client.py, the top-level client module that executes whenever any application imports the SDK. The payload downloads a WAV audio file from a command-and-control server, then extracts an XOR-encrypted executable hidden within the audio data using steganography.

On Windows, the extracted binary is dropped into the Startup folder as msbuild.exe, providing persistence across reboots. On Linux and macOS, the approach is different: a single high-speed harvesting pass collects everything of value, encrypts it with AES-256-CBC under an RSA-4096 wrapped key, exfiltrates it, and deletes its traces. Windows gets persistence; Linux and macOS get smash-and-grab.

Socket’s researchers described the tradecraft to The Hacker News:

The entire chain is designed to operate within a self-destructing temporary directory and leave near-zero forensic artifacts on the host.

— Socket, via The Hacker News

The harvester targets the same categories of developer credentials that made the AMOS stealer so effective during ClawHavoc - SSH keys, cloud CLI credentials, API tokens, .env files, and browser-stored secrets.

Why This Pattern Matters for AI Tools

The AI development ecosystem is particularly vulnerable to cascading supply chain attacks for three reasons:

1. Dense dependency graphs. AI tools depend on a deep stack of libraries - model providers, API wrappers, data processing frameworks, evaluation tools. Each dependency is a potential entry point. litellm alone serves 95 million downloads a month; every tool that depends on it, and every developer who uses those tools, was in the blast radius for the two days its malicious versions were live.

2. Elevated credential access. AI development environments routinely store API keys for model providers, cloud services, and internal APIs. A compromised package running in this environment doesn’t just get source code - it gets the keys to the entire infrastructure.

3. Fast-moving, trust-heavy culture. AI developers update dependencies frequently to access new model support, performance improvements, and features. The pressure to stay current creates an environment where version bumps are applied quickly and reviewed lightly. A 6-hour, 22-minute exposure window is long enough for every nightly CI job in a timezone to pull the bad version.

LangChain demonstrated a parallel risk highlighted this same week. Three vulnerabilities (CVE-2026-34070, CVE-2025-68664, CVE-2025-67644) — some disclosed months ago, others new — showed that even without a compromised package, the AI framework stack can expose filesystem data, environment secrets, and conversation histories through path traversal, deserialization flaws, and SQL injection. The attack surface isn’t hypothetical - it’s being actively mapped and exploited. We track the pattern across artifact types under supply chain.

What Registry-Level Verification Can and Can’t Do

Let’s be honest about the limitations. No registry can prevent a legitimate publisher’s credentials from being stolen. If TeamPCP has the real publishing token for a package, they can push a new version that looks identical to a normal update.

But a registry can make it harder for that compromised version to reach consumers undetected.

Traditional registries scan packages at upload time - if they scan at all. The problem is that when the publisher’s account is compromised, the attacker controls the upload. They can craft payloads specifically to evade the registry’s scanner, because they can test against it beforehand.

Consumer-side verification changes the equation. If the consumer independently scans the package after downloading it - using their own scanner, producing their own report - the attacker now has to evade two independent scanning passes, one of which they can’t test against in advance.

Figure: a compromised publisher controls the publish-time scan. What they cannot control is a scan that runs on the consumer’s machine against the bytes that actually arrived.

This is the core principle behind SkillSafe’s dual-side verification model, described in full in how dual-side verification works. When a skill is installed, the consumer’s machine runs a full scan and produces an independent report and tree hash. The server compares both sides. A hash mismatch - meaning the archive changed between publish and install - triggers a warning. A scan that returns a CRITICAL verdict blocks installation entirely.

Would this catch a TeamPCP-style attack on AI skills? It depends on what the payload does. Steganography hidden in a WAV file might not trigger static analysis rules. But the credential harvesting code injected into _client.py - the subprocess calls, the environment variable sweeps, the HTTP POST to a C2 server - those are exactly the patterns that AST-based scanning is designed to flag.

More importantly, the cascading nature of these attacks means that stopping one link in the chain breaks the entire cascade. If the litellm-equivalent skill had been flagged at install time, the credentials needed to compromise the next target would never have been harvested.

Practical Takeaways

Pin your dependencies. Don’t auto-update AI libraries in production. Use lockfiles, pin exact versions, and review changelogs before upgrading. The malicious Telnyx versions were live from 03:51 to 10:13 UTC - 6 hours and 22 minutes - and automated update pipelines would have pulled them without human review.

Audit your credential exposure. If a package you use has been compromised, assume your environment variables, .env files, and stored credentials were exfiltrated. Rotate everything. TeamPCP’s harvester specifically targets developer credential files matching patterns like *.env, *.pem, *secret*, *token*, and *apikey*.

Verify at install time, not just publish time. Publisher-side scanning is necessary but insufficient when the publisher’s account can be compromised. Consumer-side verification adds a layer that attackers can’t preemptively bypass.

Watch for cascading indicators. When one package in your dependency tree is compromised, check whether your credentials could give an attacker access to other packages or services. The blast radius of a supply chain attack isn’t limited to the compromised package - it extends to everything those stolen credentials can reach.

Frequently Asked Questions

What is a cascading supply chain attack?

A compromise where credentials stolen from one poisoned package are used to publish the next one. TeamPCP ran six waves between February 28 and March 27, 2026, moving from Trivy to npm, Docker Hub, KICS, litellm and telnyx. Datadog Security Labs summarized it as: “Each stage reused access or tradecraft from the one before it.”

How is a trusted package compromise different from typosquatting?

Typosquatting relies on you making a mistake at install time - a misspelled name, a confusable package. A trusted package compromise has the correct name, the real publisher account, and a normal version increment. telnyx@4.87.1 looked exactly like telnyx@4.87.0 did. Every signal a human reviewer checks says the update is legitimate.

Was my machine affected by the telnyx or litellm compromise?

Check your lockfiles for telnyx 4.87.1 or 4.87.2 and litellm 1.82.7 or 1.82.8; 1.82.6 was the last clean litellm release. If either is present, assume environment variables, .env files, SSH keys, cloud credentials and Kubernetes tokens on that host were exfiltrated, and rotate them. Datadog published indicators including the C2 host and the litellm_init.pth persistence file.

Does pinning dependencies stop this?

Pinning stops the automatic pull, which is what matters most: the telnyx window was 6 hours and 22 minutes, and unpinned CI would have caught it. It does not protect you if you upgrade into a compromised version deliberately. Pin, then review the diff and re-scan before moving the pin.

Can registry scanning catch a compromised publisher?

Only partially. When the attacker holds the real publishing token, they control the upload and can tune a payload against the registry’s own scanner before pushing. What they cannot tune against is a second, independent scan run by the consumer on the bytes that actually arrived, plus a tree-hash comparison between the two sides.

Conclusion

The shift from typosquatting to trusted package compromise represents a maturation of supply chain attacks against developer tooling. Six waves in 28 days, two of them against security scanners, one of them reaching a package with 95 million monthly downloads. The AI ecosystem, with its dense dependencies and credential-rich environments, is a natural target. The defenses need to mature at the same pace.