On March 31, 2026, attackers published malicious versions of axios—one of the most widely used HTTP client libraries in the JavaScript ecosystem. The compromised packages contained hidden dependencies designed to exfiltrate data or establish backdoor access. Sonatype's automated scanning flagged the malicious code within minutes, preventing what could have been one of the largest supply chain compromises in npm's history.
What Happened
Attackers gained publishing rights to the axios package on npm and released malicious versions that appeared legitimate at first glance. The attack vector was a hidden dependency with a name designed to evade casual inspection. When developers installed or updated axios, they unknowingly pulled in the malicious package through the dependency chain.
The attack targeted axios specifically because of its reach—over 300 million weekly downloads means a successful compromise could have affected thousands of production systems simultaneously. The malicious code was designed to execute during the installation process, before most security scanning would occur.
Timeline
March 31, 2026, early morning UTC: Attackers publish malicious axios versions to npm registry.
March 31, 2026, minutes later: Sonatype's automated repository scanning detects anomalous behavior in the new versions.
March 31, 2026, same day: Sonatype alerts npm security team and affected organizations.
March 31, 2026, same day: Malicious versions removed from npm registry.
The rapid detection and response prevented widespread installation. Organizations using automated dependency monitoring received alerts before the malicious packages entered their build pipelines.
Which Controls Failed or Were Missing
This incident reveals three critical control gaps:
Package publisher authentication: The attackers obtained legitimate publishing credentials for the axios package. Whether through credential theft, social engineering, or account compromise, the authentication mechanism failed to prevent unauthorized access. No secondary verification, like code signing or multi-party approval, existed for releases.
Dependency inspection: The malicious code hid in a transitive dependency with a name similar to legitimate packages—a classic dependency confusion attack. Most organizations don't inspect dependencies beyond the direct imports in their package.json files. Your build process pulls in dozens or hundreds of transitive dependencies automatically, and most teams have no visibility into what those packages actually do.
Installation-time execution controls: The malicious code executed during npm install, before your application code ever ran. This is by design in the npm ecosystem—packages can run arbitrary code in lifecycle scripts. Without sandboxing or execution monitoring, your CI/CD pipeline becomes an attack vector.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that you maintain an inventory of bespoke and custom software, and third-party software components. This isn't optional—if you process payment data and use axios (or any third-party library), you must track it, monitor it for vulnerabilities, and have a process to respond when compromise occurs.
NIST 800-53 Rev 5 Control SR-3 (Supply Chain Controls and Processes) requires you to employ acquisition strategies and contract tools to protect against supply chain risks. For open-source dependencies, this means:
- Verifying the integrity of packages before use
- Monitoring for unexpected changes in package behavior
- Maintaining the ability to quickly replace compromised components
ISO/IEC 27001:2022 Annex A.8.30 (Outsourced development) applies to your use of third-party code. You must apply security requirements to development involving external parties—and yes, pulling in npm packages counts as external development. You need documented processes for evaluating, approving, and monitoring external code.
OWASP Top 10 2021 A06:2021 (Vulnerable and Outdated Components) directly addresses this risk. The guidance requires you to:
- Remove unused dependencies and unnecessary features
- Continuously inventory component versions
- Only obtain components from official sources over secure links
- Monitor for unmaintained or unpatched components
Most organizations fail here not because they don't know the requirements, but because they lack the tooling to implement them at scale. When your application pulls in 400+ npm packages, manual review becomes impossible.
Lessons and Action Items for Your Team
Implement automated dependency scanning in your CI/CD pipeline. Sonatype caught this attack because they scan every new package version automatically. You need the same capability. Tools like Snyk, Socket, or Sonatype Nexus Lifecycle should fail your builds when they detect malicious code or suspicious behavior patterns. Configure these tools to run before npm install completes, not after.
Lock your dependencies with cryptographic hashes. Your package-lock.json file should contain integrity hashes for every package. When npm installs a package, it verifies the hash matches. If attackers modify a package after you've locked it, the installation fails. Run npm ci instead of npm install in CI/CD—it enforces the lock file strictly.
Audit your transitive dependencies monthly. Run npm audit and npm ls regularly. You need visibility into the full dependency tree, not just your direct imports. Look for packages with suspicious names, especially those similar to well-known libraries. Dependency confusion attacks rely on developers not noticing small naming differences.
Require multi-factor authentication for package publishing. If your team publishes packages to npm (even internal ones), enforce MFA on all publisher accounts. The axios compromise likely started with credential theft. MFA won't prevent all attacks, but it raises the bar significantly.
Sandbox your build environment. Your CI/CD pipeline should run in an isolated environment with restricted network access. If a malicious package tries to exfiltrate data during installation, your network controls should block it. Consider using tools like npm-sandbox or running builds in containers with egress filtering.
Document your dependency approval process. For PCI DSS and ISO 27001 compliance, you need written procedures for how dependencies get added to your projects. This doesn't mean manual approval for every package—it means automated controls with documented exception processes. When a new direct dependency appears in a pull request, your CI should flag it for security review.
Test your incident response for supply chain attacks. The axios incident was detected and resolved in hours. Could your team do the same? Run a tabletop exercise: a critical dependency is compromised, you have 4 hours to identify affected systems and deploy fixes. Do you know which applications use which dependencies? Can you push emergency updates outside your normal release cycle?
The axios attack succeeded initially because it exploited the trust model of open-source ecosystems. Your defenses must assume that trust will be violated. Automated detection, cryptographic verification, and defense in depth turned a potential catastrophe into a contained incident. Build those same controls into your pipeline before the next attack targets a package you depend on.
