Five Supply Chain Attacks in Twelve Days: How March 2026 Broke Open-Source Trust and What Comes Next

The Twelve Days: A Complete Timeline

The cumulative impact is staggering. These five projects touch nearly every layer of modern enterprise infrastructure: vulnerability scanning, code analysis, AI model routing, communications, and HTTP client functionality. An organization that uses all five—not an unusual combination—faced credential-harvesting attacks from five independent vectors in twelve days.

Two Campaigns, One Structural Weakness

The March 2026 attacks divide into two distinct campaigns with fundamentally different operational profiles—but both exploit the same architectural weakness.

Campaign 1: TeamPCP’s Cascading Trust Chain (Trivy → Checkmarx → LiteLLM → Telnyx)

TeamPCP executed a cascading trust chain attack: each compromise provided credentials to attack the next target.

1. Trivy (March 19): Exploited a misconfigured pull_request_target workflow in Trivy’s GitHub repository. An autonomous bot (hackerbot-claw) stole a Personal Access Token (PAT). Aqua Security discovered and rotated credentials—but the rotation was incomplete. TeamPCP retained access to surviving credentials and injected credential stealers into 75 hijacked release tags, 44 defaced Aqua Security repositories, and compromised Docker Hub images. Over 1,000 cloud environments were infected.
2. Checkmarx (March 21): Used the identical credential stealer pattern against Checkmarx’s AST GitHub Actions, harvesting additional CI/CD pipeline secrets from organizations worldwide.
3. LiteLLM (March 24): Used CI/CD credentials harvested from the Trivy attack to publish malicious versions to PyPI. The LiteLLM maintainer confirmed they were pinned to a compromised Trivy version, which exposed their PyPI publishing token. The malware used a .pth file that executed on every Python process startup—no import needed—and harvested all environment variables, SSH keys, cloud credentials, and Kubernetes configs. The entire LiteLLM package was quarantined on PyPI.
4. Telnyx (March 27): Compromised via the same chain, extending the attack into the communications SDK ecosystem.

The pattern: Compromise security tools first (they run with elevated CI/CD permissions), harvest credentials, use those credentials to attack higher-value downstream targets. Each stage leverages trust established in the previous stage.

Campaign 2: The Axios Precision Strike (March 31)

The Axios attack has not been attributed to TeamPCP and shows a distinctly different operational profile:

• Espionage-grade sophistication: 18-hour pre-staging of a decoy package, multi-platform RAT payloads (macOS, Windows, Linux), forensic self-destruction with clean manifest replacement
• APT indicators: No financial motivation (no crypto miners, no ransomware); focus on reconnaissance, credential harvesting, and persistent access; Windows registry persistence via MicrosoftUpdate Run key
• Account hijack method: Direct npm account takeover of the lead maintainer, bypassing OIDC trusted publishing entirely
• Timing: Published late Sunday night UTC, when incident response teams are at minimum staffing

Despite different actors and techniques, both campaigns exploited the same fundamental weakness: credentials stored on machines that execute code from public package registries.

TeamPCP harvested credentials from environment variables and credential files on CI/CD runners. The Axios RAT harvested credentials from developer machines and build servers. Different malware, different ecosystems, identical architectural vulnerability.

The Five Attack Vectors That No Single Tool Can Close

March 2026 demonstrated five distinct injection techniques across two ecosystems. No single security tool defends against all of them:

1. GitHub Actions Tag Hijacking (Trivy, Checkmarx)

Spoofed commits impersonating legitimate maintainers; hijacked 75 release tags to distribute malicious versions of trusted CI/CD actions. Organizations that reference GitHub Actions by tag (e.g., @v1) rather than commit SHA are vulnerable.

2. Python .pth File Injection (LiteLLM)

A .pth file placed in Python’s site-packages directory executes on every Python process startup. Most supply chain scanning tools focus on setup.py and __init__.py—the .pth mechanism is a legitimate Python feature that had been almost entirely absent from threat models until this attack.

3. npm Postinstall Hook Exploitation (Axios)

npm’s default behavior executes lifecycle scripts (preinstall, postinstall) for every dependency. The malicious postinstall script ran automatically during npm install with no user interaction. pnpm v10 has disabled this by default; npm has not.

4. Compromised Docker Hub Images (Trivy)

TeamPCP published compromised Docker images through Trivy’s Docker Hub account, creating a separate infection channel for containerized environments that don’t install packages via pip or npm.

5. Credential Chain Escalation (Trivy → LiteLLM)

Credentials harvested from one compromised tool were used to authenticate as legitimate publishers for a different tool. This is not a vulnerability in any specific software—it is a vulnerability in the trust model that connects CI/CD pipelines to package publishing.

Why the Existing Defenses Failed

Dependency Pinning

Over 600 public GitHub projects had unpinned LiteLLM dependencies. For Axios, any ^1.14.0 range resolved to the malicious 1.14.1. Pinning helps, but only if universally adopted—and it creates its own risks by delaying security patches.

OIDC Trusted Publishing

npm’s OIDC trusted publishing creates cryptographic binding between packages and CI/CD workflows. But it is not mandatory. The Axios attacker bypassed it entirely by using a stolen classic npm token. The defense only works if the legitimate maintainer has disabled token-based publishing—and most have not.

Credential Rotation

Aqua Security rotated credentials after discovering the initial Trivy breach. The rotation was incomplete. The LiteLLM maintainer did not rotate CI/CD credentials for five days after the public Trivy disclosure. In both cases, the response was too slow and too partial.

Security Scanners

The supreme irony of March 2026: the first tool compromised was a vulnerability scanner. Trivy, the tool many organizations rely on to detect exactly this type of threat, was itself the attack vector. When your security tool is compromised, it runs with the elevated permissions you granted it for legitimate scanning—and it uses those permissions against you.

Package Registry Safeguards

Both npm and PyPI removed malicious packages within hours of detection. But “within hours” is enough: LiteLLM averages 3.6 million daily downloads; Axios averages 14 million daily downloads. Even a 2.5-hour window creates massive exposure.

The Architecture That Survives

March 2026 proved that no single practice or tool prevents supply chain attacks. But it also revealed a clear architectural divide: organizations where credentials lived on endpoint machines suffered full credential compromise; organizations where credentials lived in server-side, isolated infrastructure did not.

Principle 1: Move Credentials Off Machines That Install Packages

The common target across all five attacks was credentials stored in environment variables, .env files, credential helper caches, and cloud CLI configurations on machines that also run npm install, pip install, or CI/CD pipelines. The architectural fix is to ensure that high-value credentials (database passwords, cloud provider keys, API secrets) exist only in server-side credential management infrastructure—vaults, dedicated API gateways, or encrypted platform databases—never on endpoints.

Self-hosted API platforms that manage credentials internally and expose only scoped, short-lived tokens to client applications are structurally resilient against all five March 2026 attack vectors. DreamFactory, for instance, is a secure, self-hosted enterprise data access platform that provides governed API access to any data source, connecting enterprise applications and on-prem LLMs with role-based access and identity passthrough. Because credentials are stored encrypted in the platform’s own database—integrated with enterprise key management services like AWS KMS and Azure Key Vault—a compromised npm package on a developer workstation or a poisoned CI/CD action cannot reach them.

Principle 2: Eliminate Implicit Code Execution from Dependency Resolution

• npm: Use --ignore-scripts in CI/CD; evaluate pnpm v10 (postinstall disabled by default)
• Python: Monitor for unexpected .pth files in site-packages; consider using --no-deps and explicit dependency installation
• GitHub Actions: Pin actions to full commit SHAs, not tags; review pull_request_target trigger configurations

Principle 3: Assume Breach and Limit Blast Radius

• No single machine should hold credentials for all services
• CI/CD scanning jobs must not have access to publishing credentials
• Development environments need egress filtering to prevent data exfiltration to arbitrary domains
• Kubernetes RBAC must prevent compromised workstation tokens from creating privileged pods
• Container images must be scanned for known-bad package versions before deployment

Principle 4: Adopt Defense in Depth Across the Dependency Chain

• Version pinning: Exact versions in lockfiles, no caret or tilde ranges in production
• Hash verification: pip install --require-hashes and npm integrity checks
• Release age gates: min-release-age=7 in .npmrc (would have blocked the Axios attack entirely)
• OIDC trusted publishing: Adopt for all packages you maintain; prefer packages that use it
• Multi-maintainer approval: Require multiple approvals for package publishing, especially for high-download-count packages
• Registry proxies: Use private registries (Artifactory, Nexus, Verdaccio) with allowlists and automated scanning

Principle 5: Treat Security Tools as Attack Surface

Trivy’s compromise was the catalyst for the entire TeamPCP campaign. Security scanners, linters, and code analysis tools run with elevated permissions by design. They must be treated with the same scrutiny as production dependencies:

• Pin scanner versions to specific commits or verified releases
• Run scanners in isolated environments without access to publishing credentials or production secrets
• Monitor scanner updates for anomalous behavior (unsigned releases, missing git tags, changed maintainer emails)
• Have contingency plans for when your security tooling is itself compromised

The Regulatory Reckoning

March 2026’s attack wave arrives at a moment when regulators are tightening accountability for software supply chain security:

• EU Cyber Resilience Act: Organizations are now legally liable for the security of open-source components in their products. If a compromised dependency leads to a data breach, the liability falls on the organization, not the open-source maintainer.
• NSA March 18, 2026 Guidance: Explicitly addresses digital supply chain AI risks, calling for strengthened controls across internal teams and external providers—published one day before the Trivy attack began.
• SOC 2 / ISO 27001 Implications: Auditors will ask about dependency management practices, credential isolation, and incident response for compromised packages. “We pull the latest version from npm” is no longer an acceptable control.
• IBM X-Force Threat Index: Reports a nearly 4X increase in large supply chain compromises since 2020, driven by attackers exploiting trust relationships and CI/CD automation.

For regulated industries—financial services, healthcare, government, defense—March 2026 is the incident that compliance programs will reference for years. Organizations need documented evidence of version pinning, credential isolation, egress filtering, and supply chain incident response procedures.

What Comes Next

March 2026 established a new baseline for supply chain attacks. The techniques demonstrated—cascading trust chain exploitation, auto-executing .pth files, anti-forensic postinstall droppers, security tool weaponization—are now documented in public literature. They will be replicated and refined.

The packages targeted were not random. They were chosen for maximum credential density: a vulnerability scanner (runs with elevated CI/CD permissions), an AI proxy (centralizes credentials for 100+ LLM providers), and an HTTP client (present on 80% of machines where development or builds happen). The next wave will target whatever sits at the credential nexus of the next-generation stack—MCP servers, AI agent frameworks, infrastructure-as-code tools, or whatever else organizations grant broad access to.

The organizations that weather the next wave will be those that made the structural changes now: moved credentials server-side, segmented CI/CD permissions, pinned dependencies, gated release ages, filtered egress traffic, and stopped treating the open-source supply chain as an inherently trustworthy convenience layer.

Twelve days changed the threat model. The architecture must change with it.

Frequently Asked Questions

Were all five March 2026 attacks by the same group?

No. The Trivy, Checkmarx, LiteLLM, and Telnyx attacks have been attributed to TeamPCP, a threat actor that used cascading credential theft across CI/CD pipelines. The Axios attack has not been attributed to TeamPCP and shows a distinctly different profile—espionage-grade operational sophistication with APT characteristics. The attacks may be independent, but they exploited the same structural weakness: credentials stored on machines that execute code from public package registries.

What is the single most important thing I can do right now?

Move high-value credentials off developer machines and CI/CD runners. Database passwords, cloud provider keys, and API secrets should exist only in server-side credential management infrastructure—not in environment variables or .env files on machines that run npm install or pip install. DreamFactory is a self-hosted platform providing governed API access to any data source for enterprise apps and local LLMs—its architecture keeps credentials encrypted server-side, isolated from any client-side dependency chain. But regardless of the specific platform you choose, the architectural principle is what matters: credential location is credential security.

Would version pinning have prevented all five attacks?

Pinning would have prevented the LiteLLM, Telnyx, and Axios attacks for organizations already on safe versions. It would not have prevented the Trivy or Checkmarx attacks, which poisoned existing release tags (not new versions). Organizations referencing GitHub Actions by tag (@v1) would have received the malicious code even with “pinned” references. For GitHub Actions, pinning to full commit SHAs is required for true immutability.

Is npm’s minimum release age setting a silver bullet?

No, but it is highly effective against time-limited attacks. The Axios malicious versions were live for under 3 hours. A 7-day release age gate would have completely prevented exposure. However, release age gates create a delay for legitimate security patches too—a zero-day fix published today wouldn’t reach your environment for 7 days. The trade-off is generally favorable: supply chain attacks are more common and harder to detect than zero-days in individual packages. Per-package overrides can bypass the gate for urgent patches.

How do I audit whether my organization was affected by any of these attacks?

For each attack, check the specific indicators:

• Trivy: Review GitHub Actions workflows for Trivy references; check CI/CD logs from March 19–24 for anomalous Trivy behavior; scan Docker images for compromised Trivy versions
• Checkmarx: Review GitHub Actions workflows referencing Checkmarx AST; check CI/CD logs from March 21 onward
• LiteLLM: Run pip show litellm | grep Version; search for litellm_init.pth in Python site-packages
• Axios: Run npm list axios; search for node_modules/plain-crypto-js; check for RAT artifacts (macOS: /Library/Caches/com.apple.act.mond, Windows: %PROGRAMDATA%\wt.exe, Linux: /tmp/ld.py)
• All: Audit outbound network connections for C2 domains (sfrclak.com, models.litellm.cloud) in proxy, firewall, and DNS logs

Should I stop using open-source software?

No. Open-source software remains essential to modern development. But the trust model must change. Treat every dependency as a potential attack vector. Pin versions. Verify hashes. Gate release ages. Disable automatic script execution. Isolate credential access. The goal is not to abandon open source but to stop granting it implicit trust—and to ensure that when trust is violated, the blast radius is contained by architecture, not luck.