Software Supply Chain Attacks in 2026: Why CVE Scanning Is No Longer Enough

TL;DR: Every major supply chain attack in the past 7 months — from axios to TeamPCP — bypassed traditional CVE scanners. Not because the tools were broken, but because these attacks exploit trust, not code. This post breaks down the three attack patterns, why existing defenses fail, and what engineering teams need to change.

In the past seven months, the software supply chain has been hit by a series of increasingly sophisticated attacks — each one exploiting the same fundamental weakness. Not a bug. Not a vulnerability. Trust.

The latest: on March 31, 2026, two versions of axios — a package with over 83 million weekly downloads — were published with a malicious dependency injected through a hijacked maintainer account. The attacker bypassed CI/CD entirely, published directly via stolen credentials, and the injected payload self-destructed after execution to avoid forensic detection.

Just days earlier, a threat group called TeamPCP executed what researchers are calling the most consequential CI/CD supply chain attack documented to date — cascading across five ecosystems in under a week, compromising the very security tools organizations rely on to protect themselves.

These weren't isolated incidents. They were the latest chapters in a pattern that has been escalating since mid-2025 — and one that traditional security tooling is fundamentally unequipped to handle.

How Supply Chain Attacks Actually Work: Three Patterns

These incidents weren't random. They cluster into three distinct attack patterns — each more dangerous than the last.

Pattern 1: Credential Compromise — Steal the keys, own the package. In September 2025, the maintainer of chalk and debug — packages with over a billion combined weekly downloads — was phished with a convincing, likely AI-generated email mimicking npm. Credentials and OTP handed over. Malicious versions published immediately. Close to 500 packages compromised. In March 2026, the same pattern hit axios: maintainer account hijacked, two poisoned versions published via stolen npm token, payloads designed to self-destruct after execution. npm's December token overhaul didn't stop it.

Pattern 2: CI/CD Pipeline Compromise — Don't hack the code, hack the build. In August 2025, attackers exploited a GitHub Actions workflow vulnerability in Nx (S1ngularity), gaining elevated privileges that eventually led to AWS admin access and data destruction in a downstream victim's production environment. In March 2026, TeamPCP took this pattern to its extreme — compromising Trivy, Checkmarx, LiteLLM, and the Telnyx SDK through a single stolen GitHub token. Five ecosystems breached in under a week. Over 300 GB of credentials exfiltrated. The targets were security tools themselves.

Pattern 3: Self-Propagating Malware — One infection becomes a thousand. In November 2025, Shai-Hulud 2.0 turned supply chain compromise into automated warfare. The worm harvested npm tokens and GitHub credentials, then used them to infect other packages maintained by the same developer — 796 packages, 132 million monthly downloads. If exfiltration failed, it tried to destroy the victim's entire home directory. TeamPCP's CanisterWorm later adopted the same playbook, using blockchain-based C2 to make takedowns nearly impossible.

Different techniques. Same underlying weakness.

Why These Attacks Have No CVE

Look at these incidents side by side and one thing becomes clear: none of them were caused by vulnerable code.

There was no CVE for the phishing email that compromised chalk's maintainer. No vulnerability database entry for a stolen npm token. No signature to match when a worm used legitimate credentials to publish malicious packages under a trusted name. No CVSS score could have predicted that your vulnerability scanner itself would become the attack vector.

None of these attacks exploited code.

They exploited trust.

The threat isn't in what you build. It's in what you depend on.

Why Traditional Security Scanners Miss Supply Chain Attacks

Most application security tools are designed around a simple model: scan code, match patterns, check against known vulnerability databases. This model works well for what it was built for — finding known bugs in your own code and your direct dependencies.

But supply chain attacks don't play by those rules.

A maintainer account takeover doesn't generate a CVE. A malicious dependency published under a trusted name doesn't trigger a pattern match. A self-destructing payload that erases itself after execution doesn't leave artifacts for post-hoc scanners to find. And when the compromised tool is the scanner itself — as TeamPCP demonstrated — the entire detection model collapses.

The TeamPCP campaign made this failure mode painfully explicit. Organizations that were running Trivy in every CI pipeline — the most security-conscious teams — were the ones with the greatest exposure. The tool they trusted to find threats became the threat.

This isn't a gap in coverage. It's a blind spot by design.

What Engineering Teams Should Do Differently

The lesson from the past seven months isn't that npm is broken or that open source is insecure. npm has responded with meaningful improvements, and the broader community's detection and response capabilities have been impressive. The lesson is that credential-based trust alone is not a sufficient security model for a software ecosystem at this scale.

What needs to change isn't incremental. It's structural.

Treat publishing anomalies as signals, not noise. A new version with no corresponding GitHub tag, a dependency that didn't exist 24 hours ago, a change in the maintainer's email — each of these is a weak signal. Together, they paint a clear picture. Security tooling needs to reason about these behavioral patterns, not just scan for known signatures.

Assume your dependency tree is an attack surface. Most teams audit their direct dependencies. Almost nobody audits the dependencies of those dependencies. The axios attack worked precisely because the malicious package was introduced as a transitive dependency — a layer most developers never inspect. TeamPCP went even deeper, compromising tools that operate on your dependency tree, not just packages within it. This is why full dependency visibility — not just direct dependency scanning — matters.

Move beyond CVE-based scanning. CVEs are valuable for tracking known vulnerabilities. But when the threat is a trust compromise at the distribution layer, there is no CVE to scan for. The TeamPCP campaign had no CVE, no CVSS score, and no NVD entry at the time of initial compromise. Security strategies that start and end with vulnerability databases are structurally incapable of catching this class of attack.

Don't exempt your security tools from scrutiny. TeamPCP's most important lesson may be that the tools you trust to secure your pipeline are themselves part of your attack surface. Pin GitHub Actions to full commit SHAs, not mutable version tags. Treat your security tooling dependencies with the same rigor you apply to production code.

Build organizational muscle for rapid response. When a supply chain incident hits, the first questions are: Are we affected? Which systems installed the compromised version? What credentials might be exposed? Teams that can't answer those questions within hours are operating blind during the most critical window.

Scan for behavior, not just signatures. Every attack in this timeline evaded signature-based detection. The phishing that compromised chalk had no malware signature. The axios payload self-destructed before scanners could flag it. TeamPCP's worm used legitimate credentials to publish under trusted names. The next generation of supply chain defense needs to analyze control flow and dependency behavior — not just match against known CVE databases. If your tooling can't reason about what a package does at runtime, it won't catch what's coming next. Behavioral binary analysis is one approach to closing this gap.

The Bottom Line

The npm ecosystem saw more supply chain incidents in the past seven months than in the previous five years combined. Every one of them bypassed traditional security tooling. Not because the tools were broken, but because they were designed for a different threat model.

None of these attacks exploited code. They exploited trust. Until the industry treats that distinction as a design requirement — not just a talking point — this pattern will repeat.

What Comes Next for Supply Chain Security

The software supply chain isn't going to become less of a target. It's too central to modern development, too widely trusted, and — despite ongoing improvements — still reliant on human-operated credentials that can be phished, stolen, or compromised. The rise of AI tooling adds a new dimension: packages like LiteLLM sit at the intersection of infrastructure and intelligence, holding API keys to an organization's entire AI stack. Compromising one package compromises everything downstream.

The attacks of the past seven months have shown that adversaries are adapting faster than defenses. From social engineering to self-replicating worms, from blockchain-based C2 infrastructure to coordinated multi-ecosystem campaigns, the sophistication curve is steep and accelerating. TeamPCP's reported collaboration with extortion groups suggests that supply chain compromise is becoming not just a technical threat but a business model.

This is the category of risk most tools aren't built to see. It's also the problem space we're focused on at Precogs AI — behavioral analysis across binaries and dependencies, full SBOM visibility, and the ability to surface trust failures that don't come with a CVE number. It's a hard problem, and the industry is still in the early innings of solving it.

But if March 2026 made one thing clear, it's this: the question is no longer whether your organization will be affected.

It's whether you'll know — before the damage is done.

And most teams today — won't.