Educational Purpose Disclaimer
All content on this page is provided strictly for educational and research purposes only. Unauthorized use of any technique or tool against systems you do not own is illegal under the IT Act and applicable laws worldwide. SwarupInfotech does not promote any illegal activity. Always practice in authorized lab environments only.
Axios npm Supply Chain Attack:
How North Korea Hijacked 100M Downloads
In one of the most operationally sophisticated open-source supply chain attacks ever documented, a North Korea-linked threat actor hijacked an npm maintainer's account on March 31, 2026, and deployed a cross-platform Remote Access Trojan inside two poisoned versions of Axios — a JavaScript library downloaded over 100 million times per week.
1. What Is a Software Supply Chain Attack — and Why Should You Care?
Modern software is rarely built from scratch. Virtually every application, from a startup's MVP to a Fortune 500 enterprise platform, sits on a towering stack of open-source libraries. The npm registry alone hosts over two million packages and serves billions of downloads every week. This ecosystem is phenomenally productive — and profoundly dangerous.
A software supply chain attack occurs when an adversary compromises a trusted component of the development pipeline rather than attacking the end target directly. Instead of breaching a company's firewall, attackers poison the libraries, tools, and build processes that developers implicitly trust. A single malicious dependency, installed silently by an automated CI/CD pipeline, can deliver a backdoor to thousands of downstream projects in minutes.
The appeal for attackers is obvious: one successful compromise of a widely used package multiplies their reach exponentially. Security researchers have called this the "vendor's vendor's vendor" problem — your organization may be fully patched, but your dependencies may carry hidden code from adversaries you have never heard of. The March 31, 2026 attack on Axios is a textbook illustration of this threat at maximum scale.
2. The Axios npm Compromise — What Happened on March 31, 2026
Axios is the most popular JavaScript HTTP client library in the world, used in frontend frameworks, backend Node.js services, and enterprise applications alike. Against this backdrop, a sophisticated, state-sponsored threat actor executed a precisely timed account takeover.
npm install during this period may be compromised.
According to analysis from StepSecurity and Elastic Security Labs, the attacker gained control of the npm account of jasonsaayman — one of the project's primary maintainers. The account's registered email address was silently changed to an attacker-controlled ProtonMail address: [email protected]. Using a long-lived classic npm access token obtained from the hijacked account, the attacker bypassed the repository's existing OpenID Connect (OIDC) publishing workflow and published poisoned releases directly via the npm CLI.
The attack was not impulsive. It was pre-staged approximately 18 hours before detonation, with the malicious dependency seeded on the npm registry in advance to reduce detection risk. Both the latest and legacy dist-tags were simultaneously poisoned within a 39-minute window, ensuring that any developer or automated pipeline resolving either current or older versions of Axios would pull a compromised package.
The compromised maintainer later stated publicly: "I'm trying to get support to understand how this even happened. I have 2FA/MFA on practically everything." This underscores a critical vulnerability: when both long-lived npm tokens and OIDC credentials are present in a workflow, npm defaults to the token — effectively nullifying the OIDC protection.
3. Affected Versions
The following versions of Axios should be treated as fully compromised. Any environment that installed these packages during the exposure window should assume a complete system compromise.
| Package | Version | Status | npm Tag | Action Required |
|---|---|---|---|---|
axios |
1.14.1 | MALICIOUS — REMOVED | latest |
Downgrade to [email protected] |
axios |
0.30.4 | MALICIOUS — REMOVED | legacy |
Downgrade to [email protected] |
plain-crypto-js |
4.2.1 | MALICIOUS — REMOVED | — | Remove entirely; not a legitimate dependency |
axios |
1.14.0 | SAFE | latest |
Verified clean with SLSA provenance |
axios |
0.30.3 | SAFE | legacy |
Last legitimate 0.30.x release |
A critical detection signal: the real Axios library has exactly three dependencies — follow-redirects, form-data, and proxy-from-env. The presence of plain-crypto-js in any Axios installation is unambiguous evidence of tampering, regardless of version numbering. Notably, the compromised versions do not appear in the official Axios GitHub tags, meaning npm-only installations were the primary vector.
4. Attack Mechanism — How the RAT Was Delivered
Pre-Staging the Malicious Dependency
The day before the attack, on March 30, 2026, the attacker published a clean decoy package — [email protected] — under a throwaway npm account ([email protected]). This established a publishing history on the registry designed to reduce the likelihood that automated scanners would flag the subsequent malicious version purely on account novelty. Eighteen hours later, version 4.2.1 was published with a hidden payload.
[email protected] published to build registry history[email protected] published with obfuscated RAT payload[email protected] (tagged latest)[email protected] published (tagged legacy) — both branches poisoned within 39 minutesThe Postinstall Hook: Silent Execution
The malicious [email protected] used npm's postinstall lifecycle hook to execute automatically during npm install with no user interaction required. A 4,209-byte file named setup.js employed two layers of obfuscation: reversed Base64 encoding with padding character substitution, and an XOR cipher using the key OrDeR_7077. Upon execution, the script checked the target operating system and silently downloaded a platform-specific second-stage RAT — dubbed WAVESHAPER.V2 by Google Threat Intelligence Group — from the C2 server sfrclak[.]com:8000. Separate, fully functional RAT implants were pre-built for Windows, macOS, and Linux, sharing an identical C2 protocol and command structure. According to StepSecurity, the first endpoint was compromised just 89 seconds after [email protected] was published.
5. Threat Attribution — UNC1069 / Sapphire Sleet
Google Threat Intelligence Group (GTIG) has attributed this attack to UNC1069, a financially motivated North Korea-nexus threat actor active since at least 2018. Microsoft Threat Intelligence independently attributed the same infrastructure and attack to Sapphire Sleet, its tracking designation for the same cluster of activity.
The attribution is based on the use of WAVESHAPER.V2 — an updated variant of malware previously documented in UNC1069 campaigns — and overlapping infrastructure artifacts with prior UNC1069 operations. The group focuses primarily on the finance sector, including cryptocurrency, venture capital, and blockchain organizations, with a particular interest in targets in the United States and across Asia and the Middle East. Its primary motivation is the theft of cryptocurrency wallets to generate revenue for the North Korean state.
The operational planning of this campaign — pre-staged malicious dependencies, simultaneous poisoning of two release branches, self-destructing payloads — reflects a level of sophistication that security researchers have described as deliberately designed to evade detection. As one researcher noted, this was not opportunistic: every trace was engineered to self-destruct after execution.
6. Impact — The Scale of a 100 Million Download Attack
The blast radius of this attack is difficult to overstate. Axios is the most depended-upon HTTP client in the JavaScript ecosystem, included as a dependency in millions of applications, CI/CD pipelines, and developer workstations worldwide. At the time of the incident, the library recorded over 100 million weekly downloads.
Although the malicious versions were removed within approximately three hours, the damage was already done. Huntress researchers observed over 135 endpoints across all major operating systems actively contacting the attacker's C2 infrastructure during the exposure window. CI/CD pipelines using caret ranges (^1.x) in their package.json without pinned lockfiles automatically resolved to the malicious version the moment it was published as latest.
Critically, exposure was not limited to teams that directly installed Axios. Because Axios is a transitive dependency in countless other packages, projects that never explicitly depended on Axios could still have pulled the compromised version through a secondary dependency. Any workflow that installed the malicious version with postinstall scripts enabled may have exposed all injected secrets — cloud keys, deploy keys, npm tokens, and more — to an interactive attacker with arbitrary code execution.
7. Immediate Actions for Developers and Security Teams
Step-by-Step Remediation
Audit your CI/CD pipeline logs for npm install executions that may have pulled [email protected], [email protected], or plain-crypto-js during the exposure window. Check for outbound connections to sfrclak.com or IP 142.11.206.73 on port 8000.
Downgrade to a safe version immediately. Use [email protected] for 1.x projects or [email protected] for 0.x projects. Pin exact versions in package.json by removing the caret (^) or tilde (~) prefix and managing upgrades manually.
Verify your node_modules directory. Inspect the installed Axios package's package.json for any dependency on plain-crypto-js. Its presence is unambiguous evidence of compromise. Run npm cache clean --force and reinstall in a clean environment.
Rotate all secrets and credentials immediately. If a compromised version was installed, treat every credential accessible from that environment as exfiltrated — API keys, SSH keys, cloud provider credentials, GitHub Actions tokens, npm tokens, Kubernetes service account tokens, and database connection strings. Revoke and reissue; do not rotate in place.
Rebuild compromised environments from a known-clean snapshot or base image rather than attempting to clean infected systems. Audit all deployments and roll back to safe Axios versions using dependency overrides in package.json.
Adopt OIDC Trusted Publishing for your own npm packages and ensure that long-lived npm tokens are not present in environments alongside OIDC credentials, which would allow token-based publishing to override OIDC controls.
npm audit or manually reviewing your installed package directory will not reveal the compromise after the malicious versions have been removed from the registry. There will be no postinstall script, no setup.js file, and no indication in the installed directory that anything malicious was ever installed. Active log analysis is required.
8. Other Recent npm Security Incidents in 2026
The Axios compromise did not occur in a vacuum. The first quarter of 2026 has seen an unprecedented surge in npm supply chain activity.
The Ghost Campaign — Stealing Crypto Wallets via Fake npm Packages
In late February and early March 2026, cybersecurity researchers at ReversingLabs identified a campaign dubbed the Ghost campaign — seven malicious npm packages published under a single account and designed to steal cryptocurrency wallets and sensitive credentials. The packages mimicked legitimate React and AI tooling libraries, deployed a GhostLoader RAT, and implemented a dual revenue model: primary income from credential theft via Telegram channels, and secondary income through cryptocurrency affiliate redirects stored in a Binance Smart Chain smart contract. Researchers described the February 2026 packages as likely the first wave of a larger ongoing campaign.
CanisterWorm — Blockchain-Powered Command-and-Control
In mid-March 2026, the threat actor TeamPCP — a cloud-native group first profiled in early 2026 — executed a multi-stage supply chain operation against CI/CD tooling, ultimately deploying a self-spreading npm worm called CanisterWorm. What made CanisterWorm uniquely dangerous was its use of an Internet Computer Protocol (ICP) blockchain canister as its command-and-control dead drop. Because ICP canisters run on decentralized infrastructure with no single host or provider, conventional domain takedown requests are ineffective. The worm propagated by harvesting npm authentication tokens from compromised CI runners and using them to inject malicious code into over 50 packages across multiple npm scopes. Security researchers have noted that this represents the first publicly documented npm worm to use ICP blockchain infrastructure for C2 — a technique that future threat actors are expected to adopt widely.
Malicious Strapi Plugins
Alongside these campaigns, security researchers documented a pattern of malicious plugins targeting the Strapi headless CMS ecosystem. Typosquatted and backdoored Strapi plugins were published to npm, exploiting the trust that developers place in the Strapi plugin ecosystem to deliver credential stealers and persistence mechanisms. These attacks targeted the growing market of developers building headless CMS-backed applications, where plugin installation is a routine and often automated process.
9. npm and GitHub's Security Response
The Axios incident has intensified pressure on npm and GitHub to implement systemic safeguards that reduce the risk of maintainer account takeovers and their downstream impact.
Version Cooldown Policies
One proposed and increasingly discussed control is a version publishing cooldown — a brief mandatory delay (minutes to hours) between version publication and general availability on the registry. This would create a window for automated security scanning, community review, and anomaly detection before new releases could be pulled by automated pipelines. The Axios attack, where compromised versions were available for installation within seconds of publication, illustrates precisely the gap that such a policy would address.
OIDC Trusted Publishing
npm has been actively promoting the adoption of OpenID Connect (OIDC) Trusted Publishing, which replaces long-lived static tokens with short-lived, automatically rotating credentials tied to specific CI/CD workflows. The Axios incident exposed a critical gap in this rollout: when both an npm token and OIDC credentials are present in a workflow environment, npm defaults to the token. This means partial OIDC adoption provides a false sense of security unless long-lived tokens are explicitly removed from all environments. npm has indicated that future updates will enforce OIDC-only publishing for accounts that have opted into Trusted Publishing.
10. Lessons for the Developer Community
The Axios attack is a watershed moment for open-source security. It demonstrates that even the most trusted, heavily audited packages with millions of users can be turned into attack vectors with a single stolen credential. The following practices have moved from best-effort to essential.
Pin Your Dependencies Precisely
Using caret (^) or tilde (~) version specifiers in production package.json allows automated resolution to pull any new minor or patch release — including a malicious one. Pin exact versions for critical dependencies and use npm ci (which respects lockfiles strictly) rather than npm install in CI environments.
Verify Package Provenance and Integrity
Prefer packages that publish with SLSA provenance and use npm's built-in package integrity checks. The safe version [email protected] carries SLSA provenance, giving developers cryptographic assurance that the published package was built from the official repository. A malicious version published via a stolen token would lack this provenance attestation.
Monitor Your Dependency Tree for Unexpected Changes
Tools like Snyk, Socket, and StepSecurity AI Package Analyst can detect when a package's dependency graph changes unexpectedly — such as the sudden appearance of plain-crypto-js in Axios's otherwise stable three-dependency tree. Integrate these tools into your CI pipeline and treat dependency graph changes as security events requiring review.
Use Lockfiles and Immutable Registries
Commit package-lock.json or yarn.lock files to source control and enforce their use in all CI/CD pipelines. Consider using a private npm registry proxy that caches approved versions, preventing CI pipelines from directly resolving new versions from the public registry without review.
Apply the Principle of Least Privilege to CI Secrets
CI pipelines regularly have access to cloud credentials, deploy keys, npm tokens, and database connection strings. If a postinstall script executes in that environment, all of those secrets are at risk. Isolate secret injection to the specific steps that require them, and audit token scope regularly. The CanisterWorm and Axios attacks both exploited this: broad-scoped tokens present in CI runners became the primary attack surface.
Disable Automatic postinstall Scripts Where Possible
For organizations with strict security postures, consider running npm install --ignore-scripts in CI pipelines where automated build scripts from dependencies are not required. While this may break some legitimate packages, it eliminates the primary execution vector used in postinstall-based supply chain attacks.
Conclusion
The March 31, 2026 Axios supply chain attack is a defining incident in the history of open-source security. A state-sponsored threat actor with the resources and patience to pre-stage an attack 18 hours in advance, simultaneously poison two release branches of the world's most downloaded HTTP client, and deploy platform-native RATs to Windows, macOS, and Linux — all within a three-hour window — represents a level of operational sophistication the JavaScript ecosystem has never seen directed at a single package.
The incident exposes structural vulnerabilities that go beyond any single maintainer's security practices: long-lived tokens that override modern OIDC controls, automated pipelines that execute arbitrary code from strangers' computers on every install, and a registry model where a single compromised account can distribute malware to millions of projects instantly. The developer community and registry operators now face a clear imperative: treat dependency installation as a security-critical operation, not a routine convenience.
0 Comments
If you have any doubts, then please let me know!