TL;DR: TeamPCP’s Telnyx compromise shows a repeatable supply chain pattern in which stolen credentials from one trusted tool are reused to publish malicious packages across ecosystems, with the Telnyx payload running at import time and exfiltrating data over attacker-controlled infrastructure, according to Aikido. The lesson is that package trust, CI/CD credential scope, and runtime import behavior must be governed together, not as separate controls.
At a glance
What this is: This is an analysis of the Telnyx PyPI compromise and the wider TeamPCP campaign, showing how stolen trusted credentials were used to publish malicious packages that executed on import.
Why it matters: It matters because IAM, PAM, and NHI teams need to treat build and publish credentials as high-risk identities whose compromise can turn package distribution into a cross-ecosystem malware channel.
By the numbers:
- LiteLLM serves roughly 95 million downloads per month and is increasingly deployed as a centralized LLM gateway with access to credentials for OpenAI, Anthropic, AWS Bedrock, GCP VertexAI, and more.
- Telnyx has been downloaed 742k time over the last month.
👉 Read Aikido's analysis of the Telnyx PyPI compromise and TeamPCP campaign
Context
Package compromise in software supply chains is rarely just a malware problem. It is usually an identity problem, because the attacker first has to abuse a trusted account, token, or CI/CD path before malicious code can be distributed at scale. In this case, the primary security issue is the reuse of compromised credentials across publish pipelines and ecosystems, which turns legitimate package trust into a delivery mechanism for payloads.
For identity and access programmes, the important boundary is between code publishing, build automation, and secret handling. The article shows that when an NHI such as a CI token or package-maintainer credential is stolen, the attacker can move from one compromised ecosystem into another without needing to break technical trust from scratch. That pattern is now typical of modern supply chain abuse, not an edge case.
Key questions
Q: What breaks when package publish credentials are stolen in a software supply chain?
A: A stolen publish credential turns trusted release infrastructure into an attacker-controlled distribution path. The malicious actor can publish a package that appears legitimate, reach many downstream environments quickly, and bypass user suspicion because the attack comes through normal update channels. The control failure is usually weak secret scoping, poor rotation, and missing release approval boundaries.
Q: Why do CI and package-maintainer secrets create outsized supply chain risk?
A: They create outsized risk because one credential can control many packages, many builds, or many environments at once. If those secrets are reused, long-lived, or shared across pipelines, the attacker gains a broad blast radius immediately. This is an NHI governance issue as much as a software integrity issue.
Q: What do security teams get wrong about detecting malicious packages?
A: They often focus on known-bad signatures and miss behaviour that looks legitimate until the package runs. A dependency can be harmless in static review but malicious at runtime, especially when it reads credential files, spawns subprocesses, or calls unexpected external endpoints. Behavioural telemetry is the control that closes that gap.
Q: How should organisations respond when a trusted dependency is found to be malicious?
A: Contain the environment first, then assume adjacent secrets may be exposed. Rotate credentials reachable from the affected machine, check for persistence, review outbound traffic, and rebuild from known-good sources. For package ecosystems, also verify whether publish credentials, CI tokens, or maintainer accounts were reused elsewhere.
Technical breakdown
How package publish credentials become a supply chain entry point
Package ecosystems trust authenticated publishers, so a stolen token or CI credential can be enough to push a malicious version that appears legitimate to downstream users. In this campaign, the attacker did not need to exploit the package registry itself; instead, they reused access taken from trusted tooling to sign and publish malicious artifacts. That is why build and publish credentials behave like privileged identities, not routine automation secrets. Once those credentials are compromised, the trust boundary shifts from source control to distribution.
Practical implication: Treat package publish tokens as privileged NHI credentials and scope them separately from build-time automation.
Why import-time execution is especially dangerous in Python packages
Python packages can execute code as soon as they are imported, which makes the installation and runtime boundary much weaker than many teams assume. In this case, the malicious logic sat in the client module and ran at import time, so no post-install hook or visible installer prompt was needed. That design is effective because developers often import libraries in trusted application paths, where package behavior is not tightly scrutinised. The result is silent execution in environments that believe they are only loading a dependency.
Practical implication: Review dependency risk as runtime risk, not just installation risk, and inspect imported modules in sensitive build and deploy paths.
How steganographic payload delivery evades basic content filtering
The campaign used WAV files as carriers for hidden payloads. The audio file itself was valid, which allowed it to pass basic MIME checks, while the malicious data was embedded in the frame content and decoded with XOR before execution. That means content filters looking only at file extension or declared type will miss the attack. The technique is simple but effective because it hides the payload inside an otherwise normal transport format, making detection dependent on deeper inspection and behavioral controls.
Practical implication: Add content-aware inspection and egress controls for build and runtime environments that fetch external assets.
Threat narrative
Attacker objective: The attacker objective was to turn trusted package distribution into a repeatable malware delivery channel and harvest secrets, credentials, and runtime data from downstream environments.
- Entry occurred when attackers reused stolen credentials from a trusted security or CI environment to publish malicious package versions into public registries.
- Escalation happened when the malicious package executed at import time and spawned Windows or Linux payloads without waiting for a separate installer step.
- Impact followed when the malware established persistence on Windows, exfiltrated collected data, and wrapped stolen output so only the attacker could decrypt it.
Breaches seen in the wild
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
- Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Package publishing credentials are privileged identities, not operational noise. The Telnyx compromise reinforces a governance gap that many programmes still leave unresolved: release tokens, CI secrets, and maintainer access are treated as support functions rather than high-value identities. Once those credentials are stolen, an attacker can convert trust in the publisher into trust in malicious code. That is why package publishing belongs in IAM and PAM governance, not just DevSecOps hygiene.
Import-time execution creates a hidden runtime trust boundary. Python developers often think in terms of dependency installation, but this incident shows that import time is where many malicious actions actually begin. The control gap is not simply malicious code in a package. It is the absence of runtime scrutiny around what imported modules can do once they are loaded. Practitioners should treat dependency loading as an execution event.
Steganographic transport is a named concept worth tracking. The use of valid WAV files to hide payloads illustrates a broader evasive pattern: malicious content is embedded inside a legitimate carrier so that simple inspection fails. This is not only an endpoint problem. It is a supply chain and egress governance problem because the attacker controls both delivery format and downstream retrieval. Teams need detection that looks at behavior, decoding patterns, and network destinations, not only file types.
Centralised LLM gateways and package ecosystems are converging on the same identity risk profile. The article’s numbers around high-download packages and centralised AI gateways show why one stolen identity can now create outsized blast radius. In identity terms, this is a classic standing-access problem amplified by software distribution. NHI governance frameworks need to classify publishing credentials, automation tokens, and workload secrets by blast radius, then constrain them accordingly.
Supply chain compromise is increasingly an identity lifecycle problem. The attacker’s success depends less on code novelty than on the persistence of trusted credentials beyond their intended scope. That means offboarding, rotation, and secret inventory are now part of software integrity. Practitioners should expect attackers to keep chaining compromised identities across ecosystems until lifecycle controls become mandatory rather than optional.
From our research:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- From our research: The State of Secrets in AppSec found that the average estimated time to remediate a leaked secret is 27 days, according to The State of Secrets in AppSec.
- For a broader breach lens: Review 52 NHI Breaches Analysis for recurring credential abuse and secret exposure patterns that map directly to supply chain compromise.
What this signals
Package trust is now an identity governance problem: the same controls that govern privileged human access should be applied to publish tokens, CI secrets, and workload credentials. When a package ecosystem is used as a malware delivery path, the right response is to tighten identity scope, shorten secret lifetime, and measure where trusted automation can still publish without explicit review.
Secret exposure windows are often shorter than remediation cycles: that mismatch is where attackers win. Our research shows public AWS credential exposure can be acted on in minutes, while leaked secret remediation often stretches into days, so teams need to assume compromise as soon as publication or exfiltration signals appear. The practical question is whether your pipeline can revoke and reissue at machine speed.
The Telnyx case also shows why dependency risk and runtime identity risk are converging. A malicious package is only one step away from the secrets available to the process that imports it, so the programme signal to watch is not just dependency provenance but whether build and application identities are segmented well enough to prevent lateral secret access.
For practitioners
- Classify package publish credentials as high-risk identities Separate maintainer tokens, CI publish tokens, and deployment secrets into explicit privileged identity classes with ownership, expiry, and revocation paths. Use the same lifecycle discipline you would apply to admin accounts and keep publishing access out of general build credentials.
- Pin and verify dependencies before execution Require version pinning, hash verification, and provenance checks for packages used in production builds. Where practical, block runtime loading of newly published versions until they clear review, especially for libraries that execute code at import time.
- Inspect import-time behavior in sensitive libraries Review modules that execute on import, fetch remote content, or spawn subprocesses, then add detection for those behaviors in build pipelines and developer workstations. Focus on libraries that can reach secrets, credentials, or networked infrastructure during normal application startup.
- Monitor for secret exposure after dependency compromise If a malicious package is installed, treat nearby secrets as compromised and rotate API keys, database credentials, SSH keys, and other machine identities accessible from that environment. Preserve logs and evidence before cleanup so you can identify what the package touched.
- Add egress controls for decoding and exfiltration patterns Watch for unusual fetches of audio files, base64 decoding, XOR unpacking, and encrypted outbound uploads to attacker infrastructure. These patterns often reveal the delivery and exfiltration stages even when the carrier file looks benign.
Key takeaways
- This compromise shows that package ecosystems fail when trusted publish identities are treated as low-risk operational accounts.
- The attack chain matters because import-time execution, persistence, and exfiltration can all be hidden inside a benign-looking dependency.
- Teams should respond by tightening credential scope, verifying package provenance, and rotating any secrets reachable from affected environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | The article centers on credential exposure and abuse across trusted package publishing. |
| MITRE ATT&CK | TA0006 , Credential Access; TA0003 , Persistence; TA0010 , Exfiltration | The campaign combines stolen credentials, persistence, and outbound data theft. |
| NIST CSF 2.0 | PR.AA-1 | Identity and access management must govern automation and publishing identities. |
| NIST SP 800-53 Rev 5 | IA-5 | Authenticator management directly applies to CI tokens and maintainer credentials. |
| CIS Controls v8 | CIS-5 , Account Management | Account and credential lifecycle control is central to preventing reuse across ecosystems. |
Track package compromise events against these tactics and hunt for import-time execution plus persistence indicators.
Key terms
- Package Publication Credential: A secret, token, or maintainer account used to publish software to an ecosystem registry. It is a privileged non-human identity because whoever controls it can alter what downstream users trust and install, making it a high-value target for credential theft and abuse.
- Import-time execution: Import-time execution is code that runs when a Python module is loaded rather than when a user deliberately calls a function. That behaviour matters in security reviews because it can trigger secret access, network calls, or persistence before an application has meaningfully started operating.
- Steganographic Payload Delivery: Steganographic payload delivery hides executable data inside apparently harmless files such as images or icons. Security tooling may miss the threat because the malicious content is not obvious until the file is parsed at runtime and decoded into code.
- Supply Chain Persistence: Supply chain persistence is the ability of an attacker to remain active by abusing trusted software distribution paths rather than staying on one host. It often relies on repeated publication, compromised maintainer access, or reusable automation secrets that let the attacker keep reintroducing malicious artifacts.
What's in the full analysis
Aikido's full blog covers the operational detail this post intentionally leaves for the source:
- SHA256 hashes and package names for the malicious Telnyx releases, useful for IOC-driven hunting.
- Exact Windows and Linux payload paths, including persistence behavior and exfiltration mechanics.
- The full WAV decoding technique and code path analysis that shows how the payload is unpacked at runtime.
- Specific host and network indicators, including the C2 address and exfiltration header details.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It is suitable for practitioners building stronger control over machine and automation identities across development and production environments.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org