The Axios npm Hack: How Attackers Silently Installed a Trojan on Hundreds of Developer Machines — And What Every Business Must Do Right Now

The Most Widely Used JavaScript Library in the World Was Weaponised for Nearly Three Hours on March 31. Here Is the Complete Story — From How It Happened to What It Stole to How to Find Out If You Were Hit.

Published: April 2, 2026 | By the Kersai Research Team | Reading Time: ~22 minutes
Last Updated: April 2, 2026

Quick Summary: On March 31, 2026, attackers hijacked the npm account of Jason Saayman — the lead maintainer of Axios, a JavaScript HTTP library with over 400 million monthly downloads — and published two poisoned versions: [email protected] and [email protected]. Both versions silently installed a hidden dependency called plain-crypto-js that acted as a Remote Access Trojan (RAT) dropper — contacting an attacker-controlled server, downloading malware tailored to the victim’s operating system (Windows, macOS, or Linux), stealing stored credentials and API keys, then deleting its own traces to avoid detection. The malicious versions were live for approximately three hours before npm removed them. Security firm Huntress confirmed at least 135 endpoints compromised. The attack coincided with the accidental Claude Code source code leak, dramatically amplifying the number of developers installing or updating Claude Code — and therefore axios — during the exposure window. Early attribution points to BlueNoroff, a financially-motivated subgroup of North Korea’s Lazarus Group. This is the most important developer security story of 2026. This guide explains exactly what happened, how the attack works technically, how to determine if you were affected, and the concrete steps every developer and business must take to protect against the next one.

⚠️ IMMEDIATE ACTION REQUIRED

If you or your developers ran npm install or updated any npm packages on March 31, 2026 between 00:21 UTC and 03:15 UTC (10:21 AM–1:15 PM AEST), your system may be compromised.

Do not wait until you finish reading this article. Take these four steps right now:

1. Check your lockfile — open package-lock.json or yarn.lock and search for [email protected], [email protected], or plain-crypto-js. If either appears, your system is compromised.
2. Rotate all credentials immediately — every API key, database password, SSH key, cloud access key, and secret stored on the affected machine. Assume all have been exfiltrated.
3. Isolate the affected machine from your network pending a full security investigation.
4. Alert your security team — if you do not have one, contact a cybersecurity incident response provider today.

Table of Contents

1. What Is Axios — And Why Did Attackers Target It?
2. The Attack Timeline: How Three Hours Changed Everything
3. How the Attack Actually Worked: A Technical Walkthrough
4. What the Malware Did Once It Was on Your Machine
5. The Claude Code Connection: Why More Developers Were Affected Than Usual
6. Who Did This? The TeamPCP Campaign and BlueNoroff Attribution
7. The Broader Campaign: Four Other Libraries Compromised in Two Weeks
8. How Many People Were Affected?
9. The Typosquatting Follow-On: The Second Wave of Risk
10. Step-by-Step: How to Check If You Were Compromised
11. Step-by-Step: How to Respond If You Were Hit
12. How to Protect Your Business From the Next Supply Chain Attack
13. What This Means for Australian Businesses and Their Software Supply Chains
14. FAQ

1. What Is Axios — And Why Did Attackers Target It?

1.1 What Axios is

If you have ever used a web application that makes a request to a server — loading your social media feed, processing a payment, fetching weather data, querying an API — there is a high probability that JavaScript code running somewhere in that transaction used Axios.

Axios is an open-source JavaScript HTTP client library. It is the standard tool developers use to make HTTP requests in JavaScript applications — both in web browsers and in Node.js server environments. First published in 2014, it has become one of the most ubiquitously installed packages in the JavaScript ecosystem.

The scale of its adoption is difficult to overstate:

• Over 400 million downloads per month on npm — the world’s largest software registry
• Over 100 million downloads per week
• Used by millions of applications across virtually every industry and technology stack
• Installed as a dependency in hundreds of thousands of other npm packages, meaning it reaches systems far beyond those that explicitly install it

Axios’s ubiquity is exactly what made it an attractive target.

1.2 Why supply chain attacks target libraries like Axios

A supply chain attack exploits a fundamental characteristic of modern software development: developers trust the packages they install from registries like npm. When a developer runs npm install axios, they assume they are getting the same code they have always used — the open-source code reviewed by thousands of developers worldwide.

Supply chain attacks weaponise that trust. Rather than attacking an application directly — which requires bypassing its specific security controls — attackers compromise a library that the application depends on. The library then becomes the attack vector, reaching every system that installs it.

The maths of why this is devastating: Axios has 400 million monthly downloads. If an attacker can inject malicious code into even one release for even a few hours, the potential reach extends to millions of developer workstations, CI/CD build pipelines, and production servers — all of which trusted the package enough to install it without question.

Axios is the perfect supply chain attack target:

• Massive install base: 400 million monthly downloads means even a brief attack window reaches enormous numbers of systems
• Implicit trust: Axios is so established that developers install it without scrutiny
• Deep transitive dependency: Hundreds of thousands of other npm packages depend on Axios — meaning compromising Axios compromises all of them too
• Critical path placement: As an HTTP client, Axios runs in virtually every modern web application’s request lifecycle — ideally positioned to intercept credentials and data

2. The Attack Timeline: How Three Hours Changed Everything

The Axios attack was executed with precision timing — designed to maximise the exposure window while minimising the chance of early detection.

The critical window: 00:21 to 03:15 UTC — approximately 2 hours and 54 minutes.

Any developer, CI/CD pipeline, or automated deployment system that ran npm install axios (or any equivalent command) during this window received the malicious version. Given that Sunday night in UTC is Monday morning in Australia and Asia — a high-activity development period for APAC developers — the timing exposed a geographically diverse range of victims.

2.1 How the attacker gained access

The account compromise followed a pattern investigators have seen repeatedly in recent supply chain attacks:

1. Credential theft: The attacker obtained Jason Saayman’s long-lived npm authentication token — likely through phishing, credential stuffing against reused passwords, or a prior data breach
2. Account takeover: Using the stolen token, the attacker changed the registered email on the jasonsaayman npm account to [email protected] — an attacker-controlled ProtonMail address
3. Bypassing release safeguards: The Axios project uses GitHub’s OIDC-based trusted publishing system — a security control that should require package releases to come through verified GitHub Actions workflows. The attacker bypassed this entirely by publishing directly using the compromised npm token, without any matching GitHub commit or workflow run

The bypass of OIDC trusted publishing is the most technically significant aspect of the attack. This security control is specifically designed to prevent exactly this scenario — but it only protects against attackers who lack the account owner’s npm token. With the token, the attacker had everything they needed to publish as if they were the legitimate maintainer.

3. How the Attack Actually Worked: A Technical Walkthrough

Understanding the attack mechanism is important for developers and business leaders — not because you need to reproduce it, but because understanding how it works illuminates why it was so difficult to detect and why the remediation steps are what they are.

3.1 The hidden dependency injection

The malicious [email protected] package was identical to the legitimate [email protected] in every visible way — the axios source code itself was unchanged. A developer reviewing the axios package would see nothing different.

The attack was hidden in a new dependency quietly added to axios’s package.json:

"dependencies": {
  "plain-crypto-js": "4.2.1"
}

[email protected] is a completely fabricated package — a typosquat impersonating the legitimate crypto-js library. It was published from a separate throwaway npm account, with no legitimate history, no source code on GitHub, and no documentation. Its entire purpose was to serve as the malware delivery mechanism.

When npm resolves dependencies during installation, it installs plain-crypto-js automatically as part of installing axios. The developer never sees it, never consented to it, and may never know it is there.

3.2 The postinstall dropper

[email protected] contains a postinstall script — a npm feature that runs automatically when a package is installed. Legitimate packages use postinstall for setup tasks like compiling native code. Malicious packages use it to execute arbitrary code the moment installation completes.

The postinstall script in plain-crypto-js is heavily obfuscated — multiple layers of encoding designed to defeat automated scanning tools. When deobfuscated (as security researchers from Socket, Huntress, and SANS did within hours of the attack), the script performs a simple but devastating function: it contacts an attacker-controlled command-and-control (C2) server and downloads a platform-specific second-stage payload.

3.3 The multi-platform RAT payloads

The C2 server delivers different malware payloads depending on the victim’s operating system — ensuring maximum impact regardless of the developer’s platform:

Security researcher Joe Desimone from Elastic Security captured and reverse-engineered the macOS second-stage binary before the C2 server went offline. His analysis confirmed it is a fully functional Remote Access Trojan — not just a credential stealer, but a persistent backdoor giving the attacker ongoing access to the compromised machine.

3.4 The anti-forensics cleanup

The most sophisticated element of the attack: after the RAT payload is installed and connects to the C2 server, the malware deletes all traces of its own installation:

• The postinstall script removes itself
• plain-crypto-js‘s package.json is replaced with a clean-looking placeholder
• Installation artefacts are deleted
• The malicious dependency reference is removed from the visible package structure

The result: a developer who installs the malicious axios version, has their machine compromised, and then examines their installation would find a completely normal-looking axios install. Nothing in the local files would indicate the attack had occurred — only network forensics and memory analysis would reveal the compromise.

This cleanup mechanism is specifically designed to defeat the most common developer security response: “I’ll check what was installed.” On a compromised system, that check will show nothing suspicious.

4. What the Malware Did Once It Was on Your Machine

Once the RAT payload establishes connection with the attacker’s C2 server, it executes a prioritised sequence of high-value data exfiltration:

4.1 Credential harvesting (immediate)

The RAT’s first priority is extracting credentials before any defensive action can be taken. The specific targets:

Cloud access credentials:

• AWS credentials files (~/.aws/credentials)
• Google Cloud service account keys
• Azure authentication tokens
• Any environment variables containing strings like KEY, SECRET, TOKEN, PASSWORD, CREDENTIAL

Development credentials:

• .npmrc files (which may contain npm tokens and registry credentials)
• .gitconfig and git credential stores
• SSH private keys (~/.ssh/id_rsa, ~/.ssh/id_ed25519, and any other key files in the SSH directory)
• GitHub personal access tokens stored in system credential managers

Application credentials:

• Browser-stored passwords (Chrome, Firefox, Safari credential databases)
• macOS Keychain contents (on Mac victims)
• Database connection strings in common configuration file locations
• API keys in .env files and application configuration directories

IDE and tool credentials:

• VS Code extension authentication tokens
• JetBrains IDE stored credentials
• Docker Hub and container registry credentials

4.2 System reconnaissance

Simultaneously with credential harvesting, the RAT collects system information that helps the attacker understand the value of the compromised machine and plan further exploitation:

• Operating system version and hardware specifications
• Network configuration and internal IP ranges
• List of running processes (identifying security tools, development environments, corporate software)
• Installed applications
• List of accessible network shares and drives
• User account names and group memberships

4.3 Persistent access establishment

After the initial data exfiltration, the RAT installs mechanisms for persistent access — ensuring the attacker retains control even after a system restart:

• macOS: LaunchAgent persistence item added to the user’s Library
• Windows: Registry Run key or scheduled task added for startup persistence
• Linux: Cron job or systemd user service added for persistence

This persistent access is the most dangerous long-term consequence of the attack. A developer who was compromised, rotated their credentials, and never investigated further may still have the attacker’s persistent access mechanism on their machine — giving the attacker the ability to re-harvest credentials and re-establish data exfiltration months after the initial attack.

5. The Claude Code Connection: Why More Developers Were Affected Than Usual

The Axios supply chain attack did not occur in isolation. It landed on the same day as the Claude Code source code leak — and the coincidence dramatically amplified the number of developers installing or updating npm packages during the attack window.

5.1 The amplification mechanism

When the Claude Code source code leak went viral on March 31 — accumulating 28.8 million views on X within hours — the developer community’s instinct was to install and examine the leaked code. Thousands of developers ran:

npm install @anthropic-ai/claude-code

Or updated their existing Claude Code installation to the latest version. This update process also triggers npm install for all dependencies — including axios, which is a transitive dependency of Claude Code.

The result: the viral excitement around the Claude Code leak drove a spike in npm activity at precisely the hours when the malicious axios versions were live. Developers who had no intention of installing axios directly were inadvertently exposed through their Claude Code installation or update.

The Huntress incident report noted this explicitly: “The exposure window coincided with the Claude Code npm leak going viral, which significantly increased the number of developers running npm installs during this specific time period.”

5.2 The CI/CD amplification

Beyond individual developer workstations, the attack’s impact extended into corporate CI/CD pipelines. Many CI/CD systems are configured to always install the latest compatible version of dependencies — if your pipeline ran a build between 00:21 and 03:15 UTC and axios was a dependency (directly or transitively), your build environment received the malicious version.

One particularly concerning detail from Huntress’s incident report: investigators found the malicious plain-crypto-js dependency not just in direct axios installations, but nested deep within a WordPress deployment — at node_modules/@wordpress/scripts/node_modules/plain-crypto-js. This confirms the attack propagated through transitive dependencies across entirely different package ecosystems and use cases.

6. Who Did This? The TeamPCP Campaign and BlueNoroff Attribution

6.1 The TeamPCP campaign

Early analysis from security researchers confirmed that the Axios attack is part of a coordinated supply chain campaign called TeamPCP. Between March 19 and March 31, 2026, TeamPCP compromised five widely-used open-source libraries in rapid succession:

The Axios attack was the campaign’s largest and most ambitious target — by several orders of magnitude. The earlier four targets provided the attackers with reconnaissance data, tooling refinement, and a pattern of operation that they deployed at scale against Axios.

6.2 The BlueNoroff attribution

GitHub security researcher N3mes1s published a comprehensive reverse engineering and attribution analysis that assigns the Axios attack to BlueNoroff — with high confidence.

BlueNoroff is a financially-motivated subgroup of Lazarus Group, North Korea’s most capable and active state-sponsored threat actor. BlueNoroff’s primary targets are cryptocurrency exchanges, DeFi platforms, fintech companies, and — increasingly — AI and software development infrastructure.

The attribution evidence cited in the analysis:

• Malware architecture matching BlueNoroff’s known cross-platform RAT framework, used in multiple prior campaigns
• C2 infrastructure overlapping with IP addresses and domain patterns previously attributed to BlueNoroff in 2024 and 2025 campaigns
• Credential harvesting targeting consistent with BlueNoroff’s prioritisation of crypto wallet files, exchange API keys, and cloud credentials
• Anti-forensics cleanup matching the specific implementation used in BlueNoroff’s “KANDYKORN” campaign targeting macOS cryptocurrency developers in 2024
• Timing and targeting logic consistent with BlueNoroff’s pattern of targeting widely-used developer infrastructure to maximise reach toward high-value victims

The North Korean state attribution is important context for understanding the threat actor’s motivation and sophistication. This is not a criminal opportunist or a hacktivist. This is a nation-state intelligence operation with billions of dollars in cryptocurrency theft funding its operations — running professional, methodical supply chain attacks as a core revenue generation strategy.

7. The Broader Campaign: Four Other Libraries Compromised in Two Weeks

The Axios attack is the most visible tip of a two-week supply chain campaign that has compromised developer tooling across multiple ecosystems. Each of the prior targets deserves attention because your organisation may have been exposed through them before the Axios attack even occurred.

7.1 LiteLLM (March 24, PyPI)

LiteLLM is an open-source Python library that provides a unified interface for calling multiple AI APIs — including Anthropic, OpenAI, and Google. It is widely used by developers building AI-powered applications, including many businesses using Claude in their workflows. The malicious LiteLLM version similarly contained a hidden dependency that installed credential-harvesting malware. If your development team has worked with AI APIs in Python and ran pip install litellm in the last two weeks, check your Python environments immediately.

7.2 Telnyx (March 27, PyPI)

Telnyx is a communications platform library used by developers building voice, SMS, and messaging applications. The compromised version targeted Telnyx API credentials specifically — potentially exposing communications infrastructure to attacker control. Businesses using Telnyx for customer communications should audit their API key usage for the past week.

7.3 Trivy and KICS (March 19–23)

Trivy (a container vulnerability scanner) and KICS (a infrastructure-as-code security scanner) are security tools used predominantly in DevSecOps pipelines. The irony of security tooling being compromised in a supply chain attack is grimly apt. Build pipelines running these tools during the compromise window should be treated as potentially affected environments.

8. How Many People Were Affected?

The honest answer: we do not know, and we will not know for weeks or months.

What we do know:

• Huntress confirmed at least 135 endpoints contacting the attacker’s C2 infrastructure — within their partner base alone, which represents a fraction of the total affected population
• The C2 server went offline within hours of the attack being detected — this is standard procedure for nation-state attackers and means many compromised machines may have been unable to complete their connection, limiting the exfiltration that occurred
• Security researcher Joe Desimone captured the macOS payload before C2 went offline — but researchers were not able to fully analyse the Windows and Linux payloads in real time
• Given 400 million monthly downloads, the number of installs during a three-hour window is plausibly in the tens of thousands to hundreds of thousands — the actual number of fully compromised systems is almost certainly a fraction of that, but could still be in the thousands

The more important number: the unknown compromised systems — machines where the malware successfully installed, the cleanup ran, the credentials were exfiltrated, and the persistent access mechanism was established, but the developer never knew it happened. These systems remain compromised and continue to provide the attacker with ongoing access, potentially for months, until they are identified and remediated.

9. The Typosquatting Follow-On: The Second Wave of Risk

After the Axios attack became public and the leaked Claude Code source code began circulating on GitHub, a secondary wave of attacks emerged: typosquatting packages targeting developers trying to compile the leaked code.

Security researcher Clément Dumas identified multiple malicious npm packages published by an account called “pacifier136” — packages whose names match internal packages referenced in the leaked Claude Code source code. These packages appear in the leaked code’s import statements, meaning developers who clone the leaked repository and run npm install to compile it will automatically request these packages from npm.

Currently the packages are empty stubs — they install nothing and do nothing. But the pattern is established: if “pacifier136” or other attackers push malicious updates to these package names, every developer who previously installed them will receive the malicious update automatically.

The clear guidance: do not clone, compile, or run the leaked Claude Code source code. The risk is not theoretical — the infrastructure for a follow-on supply chain attack targeting exactly this behaviour is already in place.

10. Step-by-Step: How to Check If You Were Compromised

Work through each of these steps methodically. Do not skip steps.

Step 1: Check your lockfile for the malicious versions

For npm projects
grep -r "[email protected]|[email protected]|plain-crypto-js" package-lock.json

For yarn projects
grep -r "[email protected]|[email protected]|plain-crypto-js" yarn.lock

For pnpm projects
grep -r "[email protected]|[email protected]|plain-crypto-js" pnpm-lock.yaml

text

**If you find any match: your environment is compromised. Proceed to Section 11 immediately.**

### Step 2: Check your npm cache

Even if you have updated to a clean version, the malicious version may be cached:

bash
Check npm cache for malicious axios versions
ls ~/.npm/axios/

Check for plain-crypto-js in cache
find ~/.npm -name “plain-crypto-js” -type d

text

If found, clear your npm cache: npm cache clean --force

Step 3: Check your npm global installs

npm list -g | grep axios

If this shows [email protected] or [email protected], update immediately: npm install -g axios@latest

Step 4: Check for the persistence mechanism

On macOS, check for suspicious LaunchAgents:

ls ~/Library/LaunchAgents/
ls /Library/LaunchAgents/

Look for any recently added .plist files with unusual names — particularly any installed or modified around March 31, 2026.

On Windows, check Run registry keys:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

text

On Linux, check cron and systemd:

crontab -l
ls ~/.config/systemd/user/

Step 5: Check for C2 network connections

Review your network logs or firewall rules for connections to the following indicator of compromise IP addresses and domains (as of the time of publication — this list may be updated as investigation continues):

• Check your DNS query logs for domains containing strings like “cdn-static”, “update-service”, or similar generic names registered in the days before March 31, 2026
• Check outbound connections on port 443 to IP addresses that are not in your organisation’s normal traffic profile

For most organisations without a Security Operations Centre, this step requires a cybersecurity professional. If you believe you may be compromised, this is the point to engage one.

Step 6: Use automated detection tools

The following tools have been updated with signatures for this specific attack:

11. Step-by-Step: How to Respond If You Were Hit

If any step in Section 10 confirmed compromise, treat this as a full cybersecurity incident. Do not minimise it.

Immediate actions (within the hour)

1. Isolate the machine
Disconnect the compromised machine from your network — including Wi-Fi, VPN, and any shared drives. The RAT may be actively transmitting data or providing the attacker with remote access. Isolation stops this.

2. Rotate all credentials — assume everything is compromised

Work through each category systematically:

• AWS: Go to IAM console → Security Credentials → rotate or delete all access keys that existed on the machine. Enable MFA if not already active.
• Google Cloud: Go to IAM → Service Accounts → audit and rotate any service account keys. Check OAuth tokens.
• GitHub: Go to Settings → Developer Settings → Personal Access Tokens → revoke all tokens that may have been on the machine. Rotate SSH keys.
• npm: Go to npmjs.com → Access Tokens → revoke all tokens. If you have publish rights to npm packages, treat those packages as potentially compromised.
• Database credentials: Rotate all database passwords, connection strings, and access credentials.
• API keys: Rotate every API key in .env files, configuration files, and environment variables on the machine — including payment processors, communication services, cloud providers, and any SaaS tool.
• SSH keys: If the machine had SSH private keys, rotate them and remove the public key from all servers and services.
• VPN credentials: If the machine had VPN credentials, rotate them — a compromised machine with VPN access could have given the attacker a tunnel into your internal network.

3. Notify affected parties

• Your security team or IT administrator
• Any colleagues who may have been affected by shared credential exposure
• In some cases, affected customers — take legal advice on notification obligations under the Privacy Act 1988 (Australian businesses) or your applicable data protection regulation

Short-term actions (within 24–48 hours)

4. Forensic investigation
Do not wipe the compromised machine until a forensic image has been taken. The machine’s memory and disk contain evidence of what the attacker accessed, what was exfiltrated, and what persistence mechanisms were installed. A cybersecurity professional can use this evidence to scope the full impact and identify whether other systems were accessed.

5. Check connected systems
A compromised developer workstation with access to cloud infrastructure, internal servers, and production databases gives the attacker potential lateral movement capability. Audit your cloud access logs for anomalous activity in the 72 hours following March 31. Look for:

• Unusual API calls from your AWS/GCP/Azure accounts
• New IAM users or permission grants
• Unusual data access or exfiltration from S3 buckets, GCS buckets, or blob storage
• Connections to internal systems from the compromised machine’s IP address

6. Remediate and rebuild
After forensic imaging, wipe and rebuild the compromised machine from a known clean state. Do not restore from a backup taken after March 31 — assume any backup from after the attack window may contain the persistence mechanism.

12. How to Protect Your Business From the Next Supply Chain Attack

Supply chain attacks are not going away. The Axios attack is the most visible example of a threat that has been growing steadily in sophistication and frequency. Here are the concrete, implementable controls that meaningfully reduce your exposure.

Control 1: Lock your dependency versions

The simplest and most impactful control: commit your lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml) to version control and use npm ci (instead of npm install) in all CI/CD pipelines. npm ci installs exactly the versions in the lockfile — it does not pull the “latest” version of any package. If your lockfile specifies [email protected], npm ci installs 1.14.0 even if a newer version is available.

Developers who use npm ci instead of npm install during the attack window would have installed the clean [email protected] they already had in their lockfile — completely immune to the attack.

Control 2: Implement dependency scanning in your pipeline

Add automated dependency scanning as a required step in every CI/CD pipeline. The following tools all detected the malicious plain-crypto-js package within minutes of its publication:

Socket’s automated system flagged plain-crypto-js six minutes after publication — faster than human security researchers. If your pipeline had Socket running, you would have received an alert before installing the malicious package.

Control 3: Enable npm provenance and audit for package legitimacy

npm’s trusted publishing system (OIDC-based provenance) allows packages to cryptographically prove they were built from a specific GitHub repository via a verified GitHub Actions workflow. The Axios attack bypassed this because the attacker published directly using the maintainer’s token.

Enable provenance checking for your own packages, and prefer packages that publish with provenance attestations. While this would not have prevented the Axios attack (the malicious versions matched the account’s token), it raises the bar for attackers who do not have account credentials.

Control 4: Use the --ignore-scripts flag for untrusted installs

The postinstall mechanism that executed the malicious payload can be disabled globally:

npm install --ignore-scripts

Or set as a default in your .npmrc:
ignore-scripts=true

text

This prevents any postinstall script from running during npm installs — legitimate packages rarely require postinstall scripts, and the security benefit of blocking them outweighs the occasional setup inconvenience.

Note: Claude Code’s PreToolUse hook system can intercept installation commands and automatically apply --ignore-scripts — a capability that would have blocked the Axios attack entirely for users with this hook configured.

Control 5: Monitor for new dependencies appearing in lockfiles

Set up automated alerts for any PR or commit that adds a new dependency to your lockfile. An unexpected new dependency in [email protected] (plain-crypto-js) was the attack mechanism — a review process that flags unexpected dependency additions would have caught it.

GitHub’s Dependabot and many CI security tools can flag this. Make it a merge requirement, not a recommendation.

Control 6: Implement least-privilege credentials on developer machines

Developer workstations should not have cloud credentials with administrative permissions stored in plaintext environment variables or credential files. Implement:

• Temporary credentials: Use AWS IAM Identity Center, Google Workload Identity, or similar — time-limited credentials that expire and are automatically refreshed rather than long-lived keys that can be exfiltrated and used indefinitely
• Secrets management: Store production credentials in a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) — not in .env files on developer machines
• Scoped permissions: Developer machines should have only the permissions required for development, not production administrative access

13. What This Means for Australian Businesses and Their Software Supply Chains

For development teams

Every Australian business with software developers needs to complete the compromise check in Section 10 today — not next week, not when IT gets around to it. The persistence mechanism means compromised machines remain under attacker control indefinitely until actively remediated.

For businesses with multiple developers, treat this as a fleet-wide audit. Even if your primary developers were not running npm installs during the attack window, your CI/CD pipelines may have been. Check every automated build that ran on March 31, 2026 between 10:21 AM and 2:15 PM AEST.

For Australian Privacy Act compliance

If your developers use machines that process personal information about Australian individuals — customer data, employee records, patient records — and those machines were compromised, you have potential notification obligations under the Privacy Act 1988’s Notifiable Data Breaches scheme.

The NDB scheme requires notification to the OAIC and affected individuals when:

• There has been unauthorised access to or disclosure of personal information
• The breach is likely to result in serious harm to the affected individuals

A compromised developer machine with access to customer databases or personal data environments likely triggers this obligation. Take legal advice urgently if you believe development machines with access to personal data may have been compromised.

For businesses using open-source JavaScript in any capacity

The Axios attack did not require direct use of Axios. If your business uses any web application, internal tool, or SaaS platform built on Node.js, there is a meaningful probability that Axios was a transitive dependency somewhere in its stack. For customer-facing applications, audit your Node.js dependency trees for exposure. For SaaS vendors who manage your data, ask your vendors directly whether their systems were affected during the March 31 window.

The broader lesson for Australian technology risk management

The Axios attack is not an anomaly. It is the latest and largest in a series of supply chain attacks that have been accelerating in frequency and sophistication throughout 2025 and 2026. The TeamPCP campaign alone compromised five major open-source libraries in twelve days — a pace that security teams are genuinely struggling to keep up with.

Australian businesses that treat open-source software as inherently trusted are operating on an assumption that the current threat landscape has thoroughly invalidated. The controls in Section 12 are not theoretical best practices — they are the specific, implementable measures that would have prevented the Axios attack’s impact on organisations that had them in place. Implementing them is not a software engineering discussion. It is a business risk management decision.

14. FAQ

What is the Axios npm supply chain attack?

On March 31, 2026, attackers compromised the npm account of Axios’s lead maintainer and published two malicious versions: [email protected] and [email protected]. Both versions contained a hidden dependency (plain-crypto-js) that silently installed a Remote Access Trojan on any machine that ran npm install during the attack window (approximately 00:21 to 03:15 UTC). The malware stole credentials and API keys, established persistent backdoor access, then deleted its own traces. The malicious versions were live for approximately three hours before npm removed them. Axios has over 400 million monthly downloads.

Was I affected by the Axios npm hack?

You were potentially affected if you or your CI/CD pipeline ran npm install (or equivalent) on any project that includes axios as a dependency — directly or transitively — between 00:21 and 03:15 UTC on March 31, 2026 (10:21 AM to 2:15 PM AEST). Check your lockfile for [email protected], [email protected], or plain-crypto-js. If found, treat your system as compromised, rotate all credentials, and follow the incident response steps in Section 11 of this guide.

What is plain-crypto-js and why is it dangerous?

plain-crypto-js is a malicious npm package created specifically for this attack — a typosquat impersonating the legitimate crypto-js library. It contains a postinstall script that runs automatically when installed, contacts an attacker-controlled server, and downloads a Remote Access Trojan tailored to the victim’s operating system. It has no legitimate functionality. Its sole purpose is malware delivery.

Is Claude Code related to the Axios hack?

Claude Code is connected to the attack in two ways. First, Axios is a transitive dependency of Claude Code — developers who updated Claude Code during the attack window may have inadvertently received the malicious Axios version. Second, the viral spread of the Claude Code source code leak on the same day as the attack drove a spike in npm activity during the attack window, increasing the number of affected developers. Claude Code itself was not malicious — it was an innocent vector that amplified the attack’s reach.

Who was behind the Axios npm attack?

Early attribution from security researchers points to BlueNoroff — a financially-motivated subgroup of Lazarus Group, North Korea’s state-sponsored threat actor. The attribution is based on matching malware architecture, C2 infrastructure overlaps, and tactical consistency with prior BlueNoroff campaigns including the 2024 KANDYKORN campaign targeting cryptocurrency developers. The attack is part of a broader campaign called TeamPCP that compromised five open-source libraries across npm and PyPI between March 19 and March 31, 2026.

How do I protect my business from npm supply chain attacks?

The six most effective controls: (1) Use npm ci instead of npm install in all pipelines — installs exactly the locked versions rather than fetching latest; (2) Add automated dependency scanning tools like Socket or Snyk to your CI/CD pipeline; (3) Use --ignore-scripts to prevent postinstall scripts from executing; (4) Monitor lockfiles for unexpected new dependencies appearing in PRs; (5) Replace long-lived cloud credentials on developer machines with temporary, scoped credentials from a secrets manager; (6) Commit and review your lockfile in version control. Any of these controls alone would have significantly reduced the attack’s impact.

What should I do immediately if I installed [email protected]?

Immediately: (1) Isolate the machine from your network; (2) Check your lockfile for plain-crypto-js; (3) Rotate every credential and API key that existed on the machine — cloud keys, GitHub tokens, npm tokens, SSH keys, database passwords; (4) Alert your security team and treat this as a full cybersecurity incident; (5) Do not wipe the machine before taking a forensic image — the evidence it contains is needed to scope the full impact. Then follow the complete incident response steps in Section 11 of this guide.

The Bottom Line

The Axios npm attack is a watershed moment for software supply chain security — not because it is unprecedented, but because of its scale. When the most widely-used HTTP library in the JavaScript ecosystem can be weaponised for three hours against millions of developer machines, every organisation that builds software or uses software built on open-source dependencies has a supply chain security problem it may not know about.

The good news: the controls that prevent this attack are not expensive, not complex, and not particularly disruptive. npm ci instead of npm install. Lockfile review in PRs. Socket or Snyk in your pipeline. Temporary credentials instead of long-lived keys. These are not advanced enterprise security controls — they are accessible to any development team of any size.

The bad news: the threat actor behind this attack is a nation-state with billions of dollars in funding, a professional operational security posture, and a track record of escalating sophistication. They will be back. The five-library campaign in twelve days suggests a systematic, methodical targeting of developer infrastructure that will continue.

Kersai works with Australian businesses to assess their software supply chain security posture, implement developer security controls, and build the governance frameworks that protect against the next attack — before it happens. If you would like to discuss your organisation’s exposure, visit kersai.com.

This article was researched and written by the Kersai Research Team. Kersai is a global AI consultancy firm dedicated to helping enterprises confidently navigate the rapidly evolving artificial intelligence landscape — including the security risks that come with it. To learn more, visit kersai.com.