top of page

Axios npm Supply Chain Attack: Hijacked Maintainer Account Delivers RAT

  • Writer: Pranesh Shrestha
    Pranesh Shrestha
  • Apr 9
  • 5 min read

Updated: Apr 16

Date Observed: March–April 2026 

Ecosystem: npm, Node.js, CI/CD pipelines 

Targets: Axios npm package consumers: 100M+ weekly downloads across JavaScript and Node.js build environments 

Attack Type: Maintainer account compromise, malicious package publish, cross-platform RAT delivery 


Key Takeaways

  • A North Korea-linked threat actor hijacked an Axios npm maintainer account and published malicious versions containing a cross-platform Remote Access Trojan

  • Any CI/CD pipeline or developer environment that ran npm install axios during the window was potentially compromised

  • The RAT executed at install time via a postinstall script and targeted build secrets, cloud credentials, and environment tokens

  • No vulnerability was exploited, the attack used a legitimate publisher account to distribute a poisoned package

  • Build-time proxy enforcement and package stability controls are the effective defensive layer against this class of attack


Axios is one of the most widely used JavaScript HTTP client libraries on npm, with over 100 million weekly downloads. In March 2026, a North Korea-nexus threat actor compromised an Axios npm maintainer account and used that access to publish malicious package versions 1.14.1 and 0.30.4 directly to the registry. The poisoned releases contained the malicious plain-crypto-js as a dependency which was a cross-platform Remote Access Trojan capable of executing on Windows, macOS, and Linux.

Because Axios is consumed directly in CI/CD pipelines; as a build dependency, test utility, and a runtime library. The compromise window exposed automated build environments at scale. The attack required no repository modification, no CVE, and no exploit chain. A single hijacked publish account was sufficient.


Scope and Impact of the Attack


Scope

  • Axios registers over 100 million npm installs per week; one of the highest-download packages in the JavaScript ecosystem

  • Malicious versions were live on the npm registry and available for install across the entire compromise window

  • The cross-platform RAT targeted Windows, macOS, and Linux: covering the full range of CI/CD runner and developer machine environments

  • Any project running npm install or npm ci against an affected version was exposed, regardless of whether the source repository was audited

  • Attack attributed to a North Korea-nexus threat actor by Google Threat Intelligence, consistent with prior DPRK-linked software supply chain operations targeting developer tooling (UNC1069)


Impact

The full impact is still being evaluated, but early indications suggest:

  • broad exposure across systems that installed affected packages during the compromise window 

  • malicious code execution at install time means CI/CD pipelines, developer machines, and build systems may have been directly affected 

  • potential leakage of sensitive credentials, including API tokens, cloud keys, and deployment secrets 


There are currently no confirmed figures on the number of impacted organizations or financial losses. Given the scale of adoption, the potential blast radius is significant, and organizations should assume possible exposure and respond accordingly.


How the Attack Works


Stage 0: Maintainer Account Compromise

The attacker gained control of an Axios npm maintainer account via credential theft. With publish rights to the Axios package, the attacker could push any version to the registry as a trusted release. No changes were required to the Axios GitHub repository as the attack operated entirely at the registry artifact level, invisible to any control that inspects source code.


Stage 1: Malicious Version Publication

Using the compromised account, the attacker published new Axios versions 1.14.1 and 0.30.4 to npm containing an embedded cross-platform RAT. Package metadata, version number, and publisher identity all appeared legitimate. Consumers relying on the npm registry without independent artifact verification received no signal that the release had been tampered with. The malicious versions were indistinguishable from a normal patch or minor release.


Stage 2: RAT Execution at Install Time

The malicious payload executed during package installation via a postinstall lifecycle script. When a developer ran npm install or a CI runner executed npm ci, the RAT deployed silently to the host with no user prompt. On CI/CD environments, this gave the attacker immediate code execution inside the build runner with direct access to every environment variable, secret, and credential mounted in that context.


Stage 3: Persistence and Credential Exfiltration

Once deployed, the RAT established an outbound connection to attacker-controlled infrastructure. It harvested available credentials, environment variables, and system information. On CI/CD runners, this included cloud provider tokens, container registry credentials, and deployment keys injected as pipeline secrets. On developer machines, targets extended to SSH keys, shell history, and browser-stored credentials. The RAT's cross-platform design ensured consistent execution regardless of the underlying OS.


Why this Matters to DevOps and DevSecOps Teams

The Axios compromise is a direct attack on the dependency consumption layer of the software supply chain. CI/CD pipelines execute npm install continuously across thousands of repositories. A poisoned version from a high-trust, high-download source published under a legitimate account, with no repository change and no CVE which bypasses every control that operates on source code or known vulnerability databases.


Three specific risks for build and platform teams:

  1. Install-time script execution: postinstall scripts run automatically during npm install with no confirmation, giving any malicious package direct code execution on the runner at dependency resolution time.

  2. Secrets exposure in the build environment: cloud credentials, registry tokens, and deployment keys injected as CI/CD environment variables are immediately accessible to any code executing in the runner.

  3. No repository-level signal: the Axios GitHub repository was not modified; source scanning, SAST, and SCA tools operated on clean source code and had nothing to flag.


How InvisiRisk Protects Against This Attack


Network Proxy: C2 Beacon Interception at the Build Boundary

InvisiRisk BAF operates as a network proxy inside the CI/CD build environment. All outbound traffic from the runner passes through it. When the Axios RAT executed its postinstall script and attempted to beacon to attacker-controlled infrastructure, that outbound connection is intercepted and blocked before data leaves the runner. C2 callbacks and exfiltration requests are stopped in real time regardless of whether the payload matches a known signature.


Encrypted Secret Detection in Transit

BAF inspects outbound build-time requests for patterns consistent with credential exfiltration like encoded tokens, API keys, and environment variable contents in request headers or bodies. Even if the RAT attempted exfiltration over TLS, InvisiRisk detects the pattern of sensitive data leaving the build environment and blocks the transmission before it reaches the attacker.


Stability Buffer: Blocking Freshly Published Malicious Versions

InvisiRisk enforces a configurable stability buffer on package consumption. Any npm package version published within the last 48 hours is flagged and held before it can be consumed in a build. The malicious packages freshly published from the compromised maintainer account fall directly within this window. The buffer prevents newly weaponized package versions from reaching CI/CD pipelines during the highest-risk period, before the community or registries have had time to respond.


Why Build-Time Defenses Matter

The Axios compromise confirms that account takeover at the registry level is sufficient to reach millions of build environments without modifying a single line of source code. For teams running automated pipelines, the npm install step is a code execution boundary that requires the same runtime enforcement as any other untrusted input. Without network-level interception and publish-time stability controls at the build layer, the gap between malicious publication and downstream detection stays open long enough to cause serious damage.


Comments


© 2025 by InvisiRisk, Inc.

  • Twitter
  • LinkedIn
bottom of page