Axios NPM Attack: How One Hijacked Account Poisoned Millions of JavaScript Projects

A hijacked maintainer account, two poisoned package releases, and a three-hour window were all it took to threaten millions of JavaScript projects worldwide. The incident forces hard questions about how the developer community manages dependency trust.

On March 30, 2026, security firm StepSecurity identified that two malicious versions of axios — the most popular JavaScript HTTP client library, with over 100 million weekly downloads — had been published to npm. The compromised releases, axios@1.14.1 and axios@0.30.4, didn't contain a single line of malicious code in the axios source itself. Instead, the attacker injected a new dependency called plain-crypto-js@4.2.1, designed to look like the legitimate crypto-js package. Its only job: execute a postinstall script that dropped a cross-platform remote access trojan targeting macOS, Windows, and Linux machines. After running, the malware deleted itself and swapped its own package.json with a clean version to cover its tracks.

The attack vector was a compromised maintainer account. Datadog Security Labs' detailed technical analysis shows the attacker published version 1.14.1 at 00:21 UTC and 0.30.4 roughly 40 minutes later. Because 1.14.1 was tagged as latest, anyone running a bare npm install axios without a pinned version during the roughly three-hour exposure window pulled the poisoned release automatically.

StepSecurity's advisory was blunt: "If you have installed axios@1.14.1 or axios@0.30.4, assume your system is compromised."

This is one of the most significant npm supply chain attacks in recent memory, and it illuminates structural weaknesses in how the JavaScript ecosystem — and open-source dependency management more broadly — handles trust, authentication, and incident response.

How the Attack Worked

The sophistication here wasn't in the exploit itself. It was in the camouflage.

Datadog Security Labs found that the source code of the compromised 1.14.1 release was identical to the legitimate 1.14.0. The only meaningful change was in package.json: a single new dependency entry pointing to plain-crypto-js@4.2.1. That package was never imported anywhere in axios's code. It existed purely to trigger npm's postinstall hook, a mechanism that lets packages run arbitrary scripts when installed.

The postinstall script functioned as a dropper. It contacted a live command-and-control server and delivered platform-specific second-stage payloads — a RAT capable of giving the attacker persistent remote access to the infected machine. The payload targeted all three major operating systems. After execution, the malware cleaned up after itself, replacing its package manifest with a sanitized version to frustrate forensic analysis.

The hidden dependency approach is particularly insidious because automated code review tools scanning the axios source would find nothing wrong. The malice lives entirely in the dependency graph, one layer removed from the package developers and security reviewers are likely to inspect.

Datadog's analysis also examined the npm registry metadata to trace the account takeover. The registry API returns information about who published each version and the maintainers list at publication time. Comparing the metadata for 1.14.0 (the clean release) and 1.14.1 (the compromised one) revealed telltale signs that the maintainer account had been hijacked. Datadog assessed with reasonable confidence that this attack is unrelated to the TeamPCP supply chain campaign that targeted Trivy, LiteLLM, Telnyx, and Checkmarx earlier in March 2026.

The Three-Hour Window Problem

Three hours doesn't sound like much. In the npm ecosystem, it's an eternity.

Modern JavaScript development relies on automated dependency resolution. CI/CD pipelines, developer onboarding scripts, Docker builds, and cloud deployments all run npm install constantly. A library with 100 million weekly downloads — as StepSecurity describes axios — could see tens of thousands of fresh installs in a three-hour span, especially across global time zones. Every automated pipeline that ran during that window without a lockfile pinning the exact axios version would have pulled the compromised release.

This is the core structural problem: npm's default behavior favors convenience over caution. Semantic versioning (semver) ranges like ^1.14.0 are designed to automatically pull compatible patch updates. Under normal circumstances, that's a feature: you get bug fixes and security patches without manual intervention. But when a patch release is itself the attack, semver becomes the delivery mechanism.

Lockfiles (package-lock.json or yarn.lock) mitigate this by pinning exact versions after the first install. But they only help if they already exist and are respected by the build process. Fresh installs, new projects, and misconfigured pipelines remain vulnerable. And even with lockfiles, any developer who ran npm update during the window would have pulled the poisoned version.

The Dependency Trust Model Is Broken

The axios compromise is a case study in a problem the security community has been warning about for years: the open-source ecosystem's trust model doesn't scale.

npm packages can declare arbitrary dependencies, and those dependencies can run arbitrary code at install time via lifecycle scripts. The entire chain of trust flows through individual maintainer accounts. Compromise one account, and you can inject code into every project downstream. With a package as ubiquitous as axios, that downstream reaches into millions of applications, from weekend side projects to production systems at major enterprises.

This isn't a new pattern. The event-stream incident in 2018 and the ua-parser-js compromise in 2021 followed similar playbooks. What makes the axios attack notable is its scale and its stealth. The attacker didn't modify axios's code at all. They exploited the dependency graph itself, adding a package that looked plausible enough to avoid casual scrutiny and executed its payload through a mechanism — postinstall scripts — that npm runs by default.

As we explored in our coverage of emerging trends developers need to track, the increasing complexity of modern development toolchains creates new attack surfaces. AI-assisted coding tools, automated dependency updates, and rapid deployment cycles all increase the velocity at which compromised packages can propagate before anyone notices.

What Registries Can Do

npm has taken steps over the years to improve security: mandatory two-factor authentication for high-impact packages, provenance attestations, and automated malware scanning. But the axios incident shows these measures aren't sufficient. The attacker bypassed 2FA by compromising the maintainer's account directly — the exact mechanism hasn't been publicly detailed, but Datadog's registry metadata analysis confirmed the takeover. Provenance attestations, which cryptographically link a published package to its source repository and build process, would have flagged the discrepancy, but adoption remains uneven across the ecosystem.

What Developers Can Do Right Now

The immediate defensive measures are well-established, even if inconsistently practiced:

Dependency Management

• Pin exact versions in package.json and commit lockfiles to version control.
• Disable postinstall scripts for untrusted packages using --ignore-scripts or npm's ignore-scripts config option, then selectively allowlist packages that genuinely need them.

Monitoring and Auditing

• Audit dependencies regularly using npm audit and third-party tools.
• Monitor for unexpected dependency changes in CI/CD pipelines. A new transitive dependency appearing in a patch release should trigger a review.

StepSecurity is hosting a community town hall on the axios incident to discuss response strategies and longer-term mitigations.

The Funding Gap Behind the Security Gap

There's a deeper issue beneath the technical details: open-source maintainers are often under-resourced, overworked, and operating without the security infrastructure that would be standard at any commercial software company. A single compromised credential can cascade through the entire software supply chain because the people holding those credentials frequently lack access to enterprise-grade account security, dedicated security teams, or even financial compensation for their work.

Some organizations are starting to address this. In January 2026, Anthropic donated $1.5 million over two years to the Python Software Foundation, specifically targeting ecosystem security work. The funds will support the PSF's security roadmap, including protections for PyPI users against supply chain attacks, the Developer in Residence program, and core infrastructure maintenance, as announced on the PSF's discussion forum.

That's a meaningful investment, but it also highlights the disparity. The Python ecosystem has one of the better-funded foundations in open source, and a $1.5 million security-focused donation is still considered landmark. npm's ecosystem, which serves a larger volume of packages and downloads, doesn't have an equivalent centralized funding body with that kind of security mandate. The OpenJS Foundation oversees some JavaScript projects, but the sheer scale of npm's registry — over two million packages — makes comprehensive security oversight a monumental challenge.

The axios incident didn't happen because of a zero-day vulnerability or a novel exploit technique. It happened because one person's credentials were compromised, and the system's default behaviors amplified that single point of failure into a potential mass compromise. Solving that requires money, infrastructure, and institutional will.

Broader Supply Chain Security Is Under Pressure

The axios compromise doesn't exist in isolation. The broader software security landscape in early 2026 is marked by escalating supply chain attacks across ecosystems. Datadog Security Labs noted the separate TeamPCP campaign earlier in March targeting multiple open-source projects. Apple, meanwhile, has been patching older devices against the DarkSword hacking toolkit — a reminder that supply chain integrity extends beyond package managers to the entire software stack users depend on.

The pattern is consistent: attackers are targeting the infrastructure developers and users trust implicitly. Package registries, build pipelines, update mechanisms, and browser engines are all vectors. The common thread is that these systems prioritize seamless operation, and that seamlessness creates exploitable assumptions.

For enterprises, the axios incident should accelerate adoption of software bills of materials (SBOMs), which inventory every component in a deployed application. U.S. federal policy has been pushing SBOMs since the 2021 executive order on cybersecurity, but adoption in the private sector remains patchy. An SBOM wouldn't have prevented the axios compromise, but it would have made identifying affected systems dramatically faster once the attack was discovered.

What Comes Next

The axios maintainer and the npm security team moved quickly to unpublish the malicious versions once the compromise was identified. But the incident's real impact isn't measured in the three-hour window. It's measured in the confidence erosion it causes across the ecosystem.

Every time a major package is compromised, it reinforces a difficult truth: the modern software supply chain is built on implicit trust in thousands of individual maintainers, most of whom are volunteers. The technical solutions — lockfiles, provenance attestations, install script restrictions, runtime sandboxing — exist or are in development. The gap is adoption, funding, and the cultural shift required to treat dependency management as a security-critical practice rather than a convenience feature.

The JavaScript ecosystem will recover from the axios compromise. The packages have been pulled, the IOCs are published, and incident response is underway. But unless the structural incentives change — unless registries enforce stricter defaults, enterprises fund the maintainers they depend on, and developers treat npm install with the same caution they'd apply to running an unknown binary — the next compromise is a matter of when, not if.