Blog

Axios: NPM Breaches Expose Gaps in Software Supply Chain Attestation

April 2, 2026
Abhishek Verma
TLDR;

On March 31st, 2026, an attacker compromised an Axios maintainer's npm account and published two malicious versions of the library — hiding a back door inside a transitive dependency that standard security tools never flagged. Companies that were impacted scrambled to revert their builds after the fact, while Lineaje derived the full supply chain of the package — including all transitive dependencies and then individually attested every component in that package. The tampered package generated an attestation level of 1 (Lineaje Component Attestation Level) automatically raising a flag, compared the fingerprint of the downloaded package against the original source code and flagged the mismatch immediately — preventing customers from using the impacted packages.

What Happened?

An attacker gained access to the npm account of an Axios maintainer and published two malicious versions of the library: 1.14.1 and 0.30.4 on March 31st, 2026.

Axios, for context, is not a niche tool. It is one of the most widely used JavaScript libraries on the planet — over 50 million downloads a week. The kind of dependency that sits quietly inside thousands of applications, doing its job, rarely questioned.

The attacker knew this.

What the Attack Actually Did

The compromise didn't announce itself. It hid.

The malicious code was tucked inside a transitive dependency — a package called plain-crypto-js — meaning it wasn't even in Axios directly. It was one layer deeper, in something Axios depended on. Once installed, it ran an obfuscated setup.js script that:

  • Dropped an OS-specific Remote Access Trojan (RAT) onto the host machine
  • Began polling a command-and-control server (<http://sfrclak.com:8000/6202033>) every 60 seconds for instructions
  • Cleaned up after itself — removing the dropper and the post-install hook so the installation appeared completely normal

No alerts. No errors. No indication that anything was wrong.

The compromised versions have since been removed from npm. But given Axios's download volume, even a narrow exposure window carries serious data breach potential for anyone who installed those versions before the packages were pulled.

The Real Problem: Your Pipeline Didn't See It Coming

Here's the uncomfortable truth: most CI/CD tooling would not have caught this.

The attack didn't exploit a known CVE. It didn't trigger a vulnerability scanner. The package had a valid name, a real version number, and it came through the same channel every legitimate Axios release uses — the npm registry. The only difference was that the account publishing it had been compromised, and the code had been quietly tampered with.

This is the nature of a supply chain attack. More than 70% of the software in a typical application comes from external sources — open-source libraries, OS images, and third-party packages. Your CI/CD pipeline is built to test your code. It largely trusts everything else. That trust is the vulnerability.

Why Code Signing Isn't Enough

In recent years, code signing and build-system attestation frameworks — like Google's SLSA approach — have been positioned as the answer to supply chain integrity. The Axios compromise reveals their limits.

These techniques verify that a build process ran correctly and that outputs match expected signatures. What they don't verify is whether the source itself was tampered with before the build ever started. They check compliance. They don't detect tampers.

Worse, they can create a false sense of security — certifying the integrity of software they have no real visibility into.

Attestation that can't detect a tamper isn't attestation. It's paperwork.

What Actually Catches This: Software Integrity Attestation Done Right

The goal of true software integrity attestation is straightforward, even if the implementation isn't:

What you deploy should match what you built, what you built should match your source code, and what you sourced should be identical to what the original maintainer published.

That last step is where Axios breaks down — and where the right tooling catches it.

Lineaje’s supply chain attestation capability detects exactly this type of attack — ensuring that even developer-approved packages do not bring in tampered, reputable components with proven open-source provenance.

Here's how the detection process works:

In the Axios case, the source code of tampered dependency did not come from open source. Even though the package name and PURL were recognized, Lineaje's attestation engine flagged it as LCAL 1 — the highest severity tamper indicator — signaling an immediate supply chain compromise.

Any component scoring LCAL 1 requires immediate action. There is no ambiguity.

The Lesson

Supply chain attacks are not theoretical. They are happening to real libraries, through real package managers, targeting real applications — right now.

The Axios compromise is a clean illustration of why the security posture required for software supply chains is fundamentally different from what your CI/CD pipeline was designed to provide. The pipeline checks your work. Attestation checks everything else.

If your tooling can't tell you whether what you installed is identical to what the maintainer actually published, you have a blind spot. And attackers already know where it is.

Lineaje Attestation provides high-integrity detection for software supply chain tampers — across all direct and transitive dependencies, at every depth. To see it in action, schedule a demo at lineaje.com.

More on the blog