Axios is not glamorous software. It is plumbing. The JavaScript library that lets applications make HTTP requests sits quietly inside hundreds of millions of projects — frontend React apps, Node.js backend services, CI/CD pipelines, enterprise build systems, and developer tools across every industry. Most developers who use it have never thought twice about it. That invisibility is exactly what made it the perfect target.

On March 31, 2026, an attacker used hijacked credentials to publish two backdoored versions of axios to the official npm registry. The malicious packages were live for approximately two to three hours. During that window, any developer or automated system that ran npm install received a Remote Access Trojan capable of stealing credentials, establishing persistent backdoor access, and phoning home to an attacker-controlled server — all before npm had even finished resolving dependencies. Google's Threat Intelligence Group has since attributed the attack to a suspected North Korean threat actor tracked as UNC1069.

This is a detailed account of exactly what happened, how it was engineered, and what you need to do if your systems were affected.

The Attack Timeline: 18 Hours of Preparation for a Two-Hour Window

What separates this attack from opportunistic supply chain compromises is the level of pre-staging. Security researchers at StepSecurity described it as "among the most operationally sophisticated supply chain attacks ever documented against a top-10 npm package." The preparation began nearly a full day before the axios packages went live.

The 18-hour pre-staging of plain-crypto-js@4.2.0 was deliberate. Publishing a clean version of the malicious dependency the day before gave the package a brief, non-zero history on the registry, reducing the likelihood that automated security scanners would flag a brand-new package. When 4.2.1 arrived the following day, it looked like an incremental update to an established package rather than a first-time, never-seen-before dependency.

Both axios release branches — the current 1.x series and the legacy 0.30.x series — were poisoned within 39 minutes of each other. This was not accidental. Tagging both branches simultaneously as latest and legacy maximized the blast radius, ensuring that the majority of fresh installations across all projects using either the current or legacy axios API would pull a backdoored release.

How the Maintainer Account Was Compromised

The entry point was the npm account of jasonsaayman, the primary maintainer of the axios project. The attacker gained control of the account and changed the registered email address to ifstap@proton.me, an attacker-controlled ProtonMail address. This effectively locked out Jason Saayman, the legitimate owner, by redirecting account recovery and notification emails to the attacker.

The exact method used to obtain Saayman's npm credentials has not been publicly confirmed. However, the pattern is consistent with credential theft via phishing, infostealer malware, or credential stuffing from a previous data breach. What is notable is that the attacker also appears to have obtained GitHub access alongside the npm credentials, suggesting either a shared password, a compromised OAuth token, or a more targeted intrusion than a simple credential reuse attack.

Huntress researchers observed that the numbers embedded in the malware's beacon traffic — 6202033 — reverse to 3-30-2026, the date the malicious dependency was pre-staged. Whether this is a deliberate signature or an operational detail is unclear, but it confirms the attack was planned days before execution, not improvised.

The Attack Mechanism: How a Single Dependency Became a Backdoor

The technical elegance of the attack lies in what the attacker did not do. They did not modify a single line of axios source code. The axios codebase itself in versions 1.14.1 and 0.30.4 is functionally identical to legitimate releases. Any developer performing a traditional code review or diff comparison against the previous version would find nothing suspicious in the axios files.

Instead, the attacker added a single entry to package.json: a new runtime dependency on plain-crypto-js@4.2.1. The legitimate axios package has exactly three dependencies: follow-redirects, form-data, and proxy-from-env. The addition of plain-crypto-js is unambiguous tampering, but it is easy to miss without automated dependency auditing, because npm dependency trees are large and transitive dependencies are rarely inspected manually.

The plain-crypto-js@4.2.1 package itself contains a postinstall script declaration pointing to setup.js. npm's postinstall lifecycle hook executes this script automatically during npm install, requiring no user interaction and triggering before the install command even completes. The setup.js dropper uses two layers of obfuscation to evade static analysis:

• Reversed Base64 encoding with padding character substitution
• XOR cipher with the key OrDeR_7077 and a constant value of 333

Once decoded, the dropper contacts the attacker's command-and-control server at sfrclak[.]com:8000 and downloads a platform-specific second-stage RAT payload. The C2 POST requests are deliberately designed to mimic legitimate npm registry traffic using a packages.npm.org prefix — a domain that resembles the npm registry but actually belongs to the National Association of Pastoral Musicians since 1997. The technique is a SIEM evasion strategy: logs showing traffic to what appears to be an npm domain are far less likely to trigger security alerts than traffic to an obviously suspicious domain.

Snyk researchers noted that within two seconds of npm install beginning, the malware was already contacting the attacker's server — before npm had even finished resolving the rest of the dependency tree.

The RAT: One Framework, Three Platforms

What distinguishes this attack technically is the cross-platform sophistication of the second-stage payload. The attacker deployed three parallel implementations of the same Remote Access Trojan — one each for Windows, macOS, and Linux — sharing an identical C2 protocol, command structure, and beacon behavior. Elastic Security Labs described it as "a single cross-platform implant framework with platform-native implementations."

All three variants perform the same core functions immediately on execution:

• System reconnaissance: enumerating user directories, filesystem drive roots, and running processes
• Credential harvesting: targeting cloud provider credentials (AWS access keys, GCP tokens, Azure credentials), SSH private keys, npm tokens, CI/CD secrets, GitHub Actions tokens, and any values present in .env files accessible at install time
• Data exfiltration: transmitting harvested credentials to the C2 server
• Persistent backdoor: establishing ongoing remote access for the attacker

The platform-specific variants differ in their persistence mechanisms:

• Windows: Creates %PROGRAMDATA%wt.exe and writes a batch script at %PROGRAMDATA%system.bat that re-fetches the malware on every login. Adds a Registry Run key to ensure execution across reboots.
• macOS: Drops the RAT at /Library/Caches/com.apple.act.mond, mimicking a legitimate Apple system process name to avoid suspicion in process listings.
• Linux: Writes the payload to /tmp/ld.py. Less persistent than the Windows variant, but still capable of full credential harvesting during the session.

Perhaps the most dangerous aspect of the payload design is its self-deletion behavior. After execution, the malware removes the setup.js dropper and cleans the postinstall entry from plain-crypto-js/package.json on disk. Malwarebytes researchers confirmed: "Any post-infection inspection of node_modules/plain-crypto-js/package.json will show a completely clean manifest. There is no postinstall script, no setup.js file, and no indication that anything malicious was ever installed." Running npm audit or manually reviewing the installed package directory after execution will reveal nothing.

Who Was Behind This: North Korea's UNC1069

Attribution in supply chain attacks is rarely certain, but the axios attack has attracted a high-confidence assessment from one of the most credible threat intelligence organizations in the world. Google Threat Intelligence Group Chief Analyst John Hultquist confirmed in a statement to Help Net Security:

"Google Threat Intelligence Group (GTIG) is investigating the axios supply chain attack, an incident unrelated to the recent TeamPCP supply chain issues. We have attributed the attack to a suspected North Korean threat actor we track as UNC1069. North Korean hackers have deep experience with supply chain attacks, which they've historically used to steal cryptocurrency. The full breadth of this incident is still unclear, but given the popularity of the compromised package, we expect it will have far reaching impacts." John Hultquist, Chief Analyst, Google Threat Intelligence Group

North Korean state-sponsored hackers have an extensively documented history of software supply chain attacks. The Lazarus Group and affiliated clusters have previously compromised cryptocurrency exchanges, financial institutions, and software distribution pipelines, typically targeting credential theft and financial gain. The axios attack is consistent with this pattern: a broad credential sweep across developer environments and CI/CD pipelines positions the attacker to monetize stolen access in a variety of ways over the coming weeks and months.

Mandiant CTO Charles Carmakal issued a warning that extends beyond the axios incident itself, noting that the credentials stolen across recent supply chain attacks "will enable more software supply chain attacks, SaaS environment compromises leading to downstream customer compromises, ransomware and extortion events, and crypto heists over the next several days, weeks, and months." This is not a self-contained incident. It is an initial access campaign, and the downstream exploitation is still ahead.

The Broader Campaign: TeamPCP and Four Prior Victims

The axios attack did not happen in isolation. SANS Institute analysis links it to a broader supply chain campaign attributed to a threat actor tracked as TeamPCP, which struck four widely used open-source projects in rapid succession in the ten days before the axios compromise:

• March 19: Trivy vulnerability scanner compromised
• March 23: KICS infrastructure-as-code scanner compromised
• March 24: LiteLLM AI proxy library on PyPI compromised
• March 27: Telnyx communications library on PyPI compromised

In each case, the malware harvested the same categories of credentials: cloud provider keys, SSH keys, Kubernetes configuration files, and CI/CD secrets. Wiz researchers observed the attacker validating stolen credentials within hours of each compromise using TruffleHog, then conducting systematic reconnaissance across AWS services including IAM, EC2, Lambda, S3, and Secrets Manager. Whether UNC1069 and TeamPCP represent the same actor or affiliated clusters operating in coordination is still under investigation.

What is clear is that the axios attack is the largest target in a deliberate, escalating campaign against developer tooling infrastructure. Axios's 100 million weekly downloads dwarfs any of the prior targets. The blast radius potential is correspondingly larger.

The Scale of Potential Exposure

Axios is present in approximately 80% of cloud and code environments, according to Wiz research. Its weekly download count of roughly 100 million means that even a two-to-three-hour malicious window represents an enormous number of potential infections. Wiz observed active RAT execution in 3% of affected environments during the window — a figure that, applied to the scale of axios usage, translates to a significant number of compromised developer machines and CI/CD pipelines globally.

The attack is also particularly dangerous for organizations running automated build pipelines. CI/CD systems that are configured to install the latest compatible package version — the default behavior — would have silently pulled the backdoored release and executed the malware without any human ever running a command. In many enterprise environments, this means the RAT may have executed in production build environments, staging systems, and deployment pipelines before a single developer even opened their laptop on March 31.

How to Check if You Were Affected

The self-deletion behavior of the malware means you cannot rely on npm audit or inspecting node_modules after the fact. You need to check multiple signals:

Step 1: Check Your Lockfiles

Search your package-lock.json, yarn.lock, or bun.lockb for any reference to axios@1.14.1, axios@0.30.4, or plain-crypto-js. A lockfile entry for either compromised axios version, or any version of plain-crypto-js, indicates the malicious package was downloaded. Note that the lockfile records what was resolved, even if the files were later deleted.

Step 2: Check CI/CD Pipeline Logs

Review build logs for any pipeline that ran npm install, yarn install, or bun install between 00:21 and 03:29 UTC on March 31, 2026. If the log shows plain-crypto-js in the resolved dependency tree, the dropper executed.

Step 3: Check for RAT Artifacts

Look for platform-specific RAT files that survive after the dropper self-deletes:

• macOS: /Library/Caches/com.apple.act.mond
• Windows: %PROGRAMDATA%wt.exe and %PROGRAMDATA%system.bat
• Linux: /tmp/ld.py

Step 4: Check for C2 Traffic

Review network logs for outbound connections to sfrclak[.]com:8000. Also look for anomalous HTTP POST requests or beaconing behavior from systems that ran npm install during the window. The C2 traffic uses a packages.npm.org prefix to mimic npm registry traffic, so filtering for npm-like domains in unusual ports or with unexpected POST volumes may surface it.

What to Do If You Were Compromised

If any of the above checks confirm that the malicious packages executed in your environment, the response is non-negotiable: treat every affected system as fully compromised. Do not attempt to clean the RAT in place.

• Isolate the affected machine or pipeline immediately from the network
• Rebuild from a verified clean state — do not trust any artifacts from the affected environment
• Rotate every credential that was present on the machine: npm tokens, AWS access keys, GCP and Azure credentials, SSH private keys, GitHub Actions tokens, CI/CD secrets, and all values from .env files
• Rotate repository secrets and any signing keys accessible from the affected environment, as these could be used to backdoor future software releases
• Audit downstream systems: if credentials stolen from a build pipeline had access to production databases, cloud storage, or customer-facing infrastructure, those systems also need to be audited for unauthorized access
• Revert to safe axios versions: axios@1.14.0 for 1.x users, axios@0.30.3 for 0.x users, installed in a clean environment

The credential rotation step is not optional or precautionary — it is urgent. Based on the observed behavior of prior TeamPCP compromises, stolen credentials are validated and operationalized within hours of theft. If affected credentials have not already been rotated, they should be treated as actively exploitable right now.

What the Axios Attack Means for npm and Open Source Security

The axios supply chain attack is a textbook demonstration of why maintainer account security is the single most critical vulnerability in the npm ecosystem. The entire security model of npm package distribution rests on an implicit trust: that a package published under a legitimate maintainer's account is what it claims to be. The moment an attacker controls a maintainer's credentials, that trust becomes a weapon.

Snyk's analysis framed the systemic problem plainly: "This attack follows a now-familiar pattern: compromise a legitimate maintainer account, publish a malicious version of a trusted package, and rely on the ecosystem's implicit trust of registered packages." What makes axios particularly significant is not the novelty of the technique — it is the scale. 100 million weekly downloads means the npm ecosystem's trust problem is not theoretical. It is a risk that materialized in real time on March 31.

The attack also illustrates the inadequacy of traditional security tooling for supply chain threats. Standard npm audit only flags known vulnerabilities in registered packages — it cannot detect a malicious postinstall hook that has already executed and self-deleted. Source code review catches changes to the primary package's files, but not additions to the dependency tree. Lockfile pinning helps, but only if the lockfile was generated before the malicious version was published, and only if it is actually enforced in the build pipeline.

What does work, as demonstrated by the rapid detection in this case, is behavioral monitoring: automated tools that observe outbound connections made during npm install and flag anomalous network activity. StepSecurity's Harden-Runner detected the compromised axios package making unexpected outbound connections across multiple open source projects. Elastic Security Labs identified the compromise through automated supply chain monitoring before the broader community was aware. The window between publication and detection was under two hours. The response from the security community — public disclosure, registry removal, and coordinated advisories — happened within hours of that detection.

That speed matters. The malicious versions were live for approximately 190 minutes. For a package with 100 million weekly downloads, those 190 minutes represent a substantial exposure window, but the rapid community response compressed the damage window compared to attacks that go undetected for weeks or months.

What Comes Next

The immediate crisis is contained. The malicious packages have been removed from npm. The C2 infrastructure is offline. GitHub suspended the compromised account. npm placed a security hold on plain-crypto-js. For organizations that were not affected during the exposure window, there is no ongoing risk from the specific axios attack.

The downstream risk is a different matter. Based on the operational pattern of TeamPCP and the broader North Korean supply chain playbook, the credentials stolen during this campaign are likely being validated and operationalized now. Mandiant's assessment is worth repeating: the stolen secrets from the recent wave of supply chain attacks will fuel follow-on attacks — additional supply chain compromises, SaaS environment breaches, ransomware, and cryptocurrency theft — over the coming weeks and months.

Organizations that ran affected versions during the exposure window and have not yet rotated credentials are not in a waiting period — they are in an active exposure period. The attacker does not announce when they use stolen access. They use it quietly, often weeks after the initial theft, after defenders have moved on.

For the broader ecosystem, the axios attack will likely accelerate already-growing momentum behind npm security hardening: mandatory multi-factor authentication for high-download maintainer accounts, publish attestation requirements, automated behavioral analysis at the registry level for packages above download thresholds, and organizational policies requiring lockfile pinning and controlled install environments in CI/CD pipelines. The npm registry and GitHub have both taken reactive steps. Whether the ecosystem builds proactive defenses before the next UNC1069 or TeamPCP operation is a question with significant consequences for every JavaScript developer in the world.

Frequently Asked Questions

Which axios versions were compromised in the March 2026 supply chain attack?

The compromised versions are axios@1.14.1 and axios@0.30.4. Both were published on March 31, 2026 using a hijacked maintainer account. Safe versions are axios@1.14.0 for 1.x users and axios@0.30.3 for 0.x users. If you installed either compromised version between 00:21 and 03:29 UTC on March 31, 2026, treat your system as fully compromised.

What does the axios malware actually do?

The malicious axios versions include a hidden dependency, plain-crypto-js@4.2.1. When you run npm install, this package's postinstall script executes automatically and deploys a Remote Access Trojan. The RAT performs immediate system reconnaissance, steals cloud credentials, API keys, SSH keys, and .env file contents, establishes a persistent backdoor, and phones home to a command-and-control server. On Windows, it also creates a Registry Run key for persistence across reboots.

How do I check if my system was affected by the axios npm attack?

Check your package-lock.json, yarn.lock, or bun.lockb for axios@1.14.1, axios@0.30.4, or plain-crypto-js. Check for RAT artifacts on disk (paths listed in the table above). Review network logs for outbound connections to sfrclak[.]com:8000. Do not rely on npm audit alone — the malware self-deletes its traces from the installed package directory after execution.

Who was behind the axios npm supply chain attack?

Google Threat Intelligence Group has attributed the attack to a suspected North Korean threat actor tracked as UNC1069. SANS Institute analysis also links it to the broader TeamPCP supply chain campaign, which compromised four other open-source projects between March 19 and March 27, 2026, including Trivy, KICS, LiteLLM, and the Telnyx library.

What should I do if I installed axios 1.14.1 or 0.30.4?

Isolate the affected system immediately. Rebuild from a known-good state — do not attempt to clean in place. Rotate all credentials accessible on the machine: npm tokens, AWS access keys, SSH private keys, GCP and Azure credentials, CI/CD secrets, GitHub Actions tokens, and all .env file values. Then reinstall from a clean environment using the safe versions listed above.

Was axios itself modified in the supply chain attack?

No. The attacker did not modify any axios source files. They added a hidden malicious dependency, plain-crypto-js@4.2.1, to the package.json of the backdoored releases. This made the attack significantly harder to detect through code review or diff analysis, since the axios code itself appeared unchanged.