What Happened
In Q1 2026, Sonatype identified 21,764 open source malware packages across public repositories, with npm accounting for 75% of these. Three incidents highlighted how attackers exploit trust in development workflows: the SANDWORM_MODE campaign targeting CI/CD automation, the LiteLLM compromise, and notably, the axios breach affecting one of JavaScript's most widely-used HTTP libraries.
The axios incident is significant because it exploited transitive dependencies. Attackers didn't compromise axios directly—they introduced a hidden dependency on [email protected], a malicious package that executed arbitrary code wherever axios was installed.
Timeline
Early Q1 2026: Attackers publish [email protected] to npm, mimicking legitimate cryptography packages.
Mid-Q1: A version of axios is released that includes [email protected] as a transitive dependency. Most dependency scanners flag axios as safe since axios itself wasn't modified.
Late Q1: Organizations running automated dependency updates pull the compromised axios version into production. The malware executes during build processes and runtime environments.
Detection: Sonatype's research team identifies the pattern while analyzing the 21,764 malicious packages discovered in Q1. The axios compromise is classified as part of a broader trust abuse trend.
Which Controls Failed or Were Missing
Dependency Verification: Teams trusted axios based on its reputation and download count. The full dependency tree wasn't verified before integration. The transitive dependency on [email protected] went unnoticed because it was buried in the dependency graph.
Software Composition Analysis (SCA) Limitations: Standard SCA tools checked axios for known CVEs but didn't evaluate the risk profile of its dependencies. The tools reported "no vulnerabilities found" because [email protected] wasn't in any CVE database yet.
Build Environment Isolation: CI/CD pipelines ran with broad network access and elevated privileges. When [email protected] executed, it had the permissions needed to exfiltrate credentials and modify build artifacts.
Integrity Verification: No cryptographic verification of package contents occurred. Teams relied on npm's infrastructure to deliver unmodified packages but didn't validate checksums or signatures independently.
Change Detection: Automated dependency updates ran without human review. The addition of a new transitive dependency didn't trigger any alert or approval workflow.
What the Relevant Standards Require
NIST 800-53 Rev 5 SA-10 (Developer Configuration Management) requires organizations to track security flaws and configuration changes in system components during development, including third-party components. The axios incident violated SA-10 because teams didn't maintain visibility into their complete dependency tree or track when new dependencies were introduced.
PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom software be developed based on industry standards and incorporate information security throughout the software development lifecycle. Specifically, 6.3.2.c requires that software development personnel are trained in secure coding techniques. While this applies to custom code, the principle extends to dependency management—your build process is part of your development lifecycle.
ISO/IEC 27001:2022 Annex A.8.31 (Separation of Development, Test and Production Environments) requires controls to separate these environments. The axios compromise spread because build environments had production-level access. Malware executing during npm install could reach production secrets.
OWASP ASVS v4.0.3 Section 14.2 (Dependency) requires verification that all components are free of known vulnerabilities and are up to date. Requirement 14.2.3 specifically states: "Verify that third party components come from pre-defined, trusted and continually maintained repositories." The axios incident demonstrates why this must extend beyond the direct dependency to the entire transitive tree.
SOC 2 Type II CC6.6 (Logical and Physical Access Controls) requires that access to data and systems be restricted to authorized users. Build systems that automatically pull and execute code from public repositories without verification fail this control. The malware gained access because the build process was authorized to install any package from npm.
Lessons and Action Items for Your Team
Map your complete dependency tree: Run npm ls --all or equivalent for your package manager. Export this to a file and review it weekly. You're responsible for every package in that tree, not just the ones in package.json.
Implement dependency pinning with hash verification: Lock your dependencies to specific versions and verify their integrity. In npm, use package-lock.json with npm ci instead of npm install. Add checksum verification:
npm install --integrity
Configure your CI/CD to fail builds if checksums don't match.
Restrict build environment permissions: Your CI/CD runners should operate with minimal privileges. They don't need access to production databases or AWS credentials during dependency installation. Use separate service accounts for different build stages. The malware in [email protected] could only exfiltrate what your build environment could access.
Review transitive dependencies before updates: Don't auto-merge Dependabot PRs. Before accepting any dependency update, run:
npm diff <package>@<old-version> <package>@<new-version>
Check what changed in the dependency tree, not just the package itself.
Establish a package vetting process: For dependencies with more than 1,000 weekly downloads that your application directly imports, assign someone to review the package source. Look for:
- Recent maintainer changes
- New dependencies added in recent versions
- Unusual network calls or file system access
- Mismatches between package name and functionality
Implement runtime monitoring: Even with perfect vetting, assume compromise is possible. Monitor your build processes for:
- Unexpected network connections during package installation
- New processes spawned by npm/yarn
- File modifications outside expected directories
- Credential access attempts
Segment your supply chain risk: Not every service needs every dependency. If you're pulling in axios for a background job processor, that service shouldn't have the same network access as your user-facing API. Isolate components to limit blast radius.
The axios compromise succeeded because teams treated popular packages as inherently safe. With 21,764 malicious packages identified in a single quarter and npm representing 75% of that threat surface, your dependency chain is now a primary attack vector. The controls listed above map directly to compliance requirements you're already obligated to meet—now you need to extend them to the code you don't write but definitely run.
