When Trust Becomes the Attack Vector: The Axios NPM Supply-Chain Compromise

2 Apr

PureCyber Insights | When trust becomes the attack: The Axios npm supply-chain compromise

On 31 March 2026, one of the world’s most widely used JavaScript tools, Axios, was quietly turned into a delivery system for malware. For a few hours, simply running the everyday command npm install was enough to infect developer laptops, automated build systems, and cloud environments across the globe.

This wasn’t an accident or a harmless mix‑up. It was a deliberate, well‑planned supply‑chain attack that took advantage of the enormous trust placed in open‑source software.

What is Axios, and why was it targeted?

Axios is a small but hugely popular piece of software that helps applications send and receive data over the internet. If your organisation uses modern JavaScript tools, whether that’s Node.js, React, Next.js, serverless functions, or automated build pipelines, Axios is almost certainly being used behind the scenes.

Security researchers estimate that Axios appears in around 80% of environments and is downloaded more than 100 million times every week.

That level of widespread use makes Axios a highly attractive target.
If attackers can compromise it once, they can reach thousands of organisations automatically without needing to break into them individually.

What actually happened?

On 31 March 2026, attackers hijacked the npm account of Axios’ lead maintainer, then published two official, cryptographically legitimate releases directly to the npm registry:

axios@1.14.1

axios@0.30.4

These versions were live for ~2–3 hours, long enough to be pulled by:

developer machines

CI/CD pipelines

container builds

automated rebuilds

During that window, any environment that ran npm install or npm update without pinning versions could be compromised.

“There is no malicious code in Axios”

Axios itself wasn’t tampered with; Instead, attackers added a single new dependency:

plain-crypto-js@4.2.1

That package:

is never actually imported

is never referenced

serves no functional purpose

Its only job was to run a post-install script that:

Identified the operating system

Downloaded a platform‑specific implant (Windows, macOS, Linux)

Established a connection to a live command‑and‑control server

Then, deleted its own installation artefacts to hide forensic evidence

After installation, everything looked clean, even to engineers inspecting node_modules manually.

Why was this attack so effective?

This wasn’t opportunistic malware. It was engineered.

Researchers observed:

The malicious dependency was staged 18 hours in advance using a clean “decoy” version

Separate implants were pre‑built for each operating system

Both Axios branches (current and legacy) were attacked within 39 minutes

The dropper self‑deleted and replaced its own metadata to evade audits

Multiple vendors have called this one of the most operationally sophisticated npm attacks ever observed.

Who was behind it?

Multiple sources have independently attributed the activity to a North Korea‑linked threat actor tracked as UNC1069/BlueNoroff, a group historically associated with credential theft, financial intrusion, and supply‑chain compromise.

This aligns with prior DPRK tradecraft:

identity‑centric compromise

trusted‑pipeline abuse

infrastructure reuse

rapid monetisation of stolen secrets

Why “just upgrading” is not enough

This is not a vulnerability you patch. If a system installed one of the affected versions during the exposure window, then:

The malware has already executed

secrets may already be stolen

Persistence may already exist elsewhere

Downgrading Axios does not undo compromise. This incident crosses the boundary from dependency management into incident response.

Recommendations from PureCyber

PureCyber recommends taking the following actions to assess and contain any potential impact from this supply chain compromise:

For most organisations, exposure is most likely to occur through everyday software and services, including SaaS platforms, internal development tooling, Cloud processes, and general web applications.
These systems often rely on Node.js dependencies without direct visibility at the customer level.

We recommend contacting any suppliers, software vendors, or development partners whose products or services may rely on Axios or Node.js packages.
Ask them to confirm whether they are affected and whether any updates or advisory notices apply to your environment.

Where internal development teams exist, ensure they review lockfiles, build logs, npm caches, and CI runner histories during the 31 March 2026 exposure window. Even transient builds may leave traces worth investigating.

Rotate or revoke any API keys, secrets, tokens, or credentials that may have been present in build environments during the exposure timeframe.
Supply chain malware commonly targets stored credentials.

Ensure any potentially affected hosts are rebuilt from clean sources, not simply patched or rolled back.
This type of attack executes during installation and may leave persistence elsewhere on the system.

Consider enabling additional telemetry, such as endpoint monitoring, network egress filtering, and build pipeline logging, to improve visibility for future incidents of this nature.

If you are a PureCyber client: We are actively reviewing your estate using our vulnerability agent, including all monitored endpoints, servers, and mapped assets.
If we identify any indicators of compromise or evidence that the malicious packages were executed, we will contact you immediately with next steps.

The Technical Detail

How to check if you are affected

The malware used in this attack attempts to clean up after itself, so there is no 100% guarantee that any single check will catch it.

That said, there are a few high‑value locations worth reviewing to establish whether the malicious dependency was ever resolved or executed.

Search lockfiles (highest confidence, lowest noise)

Lockfiles are the authoritative record of what was actually installed, not just what was intended.

find . -type f \( -name "package-lock.json" -o -name "yarn.lock" -o -name "pnpm-lock.yaml" -o -name "bun.lockb" \) -exec grep -n "plain-crypto-js" {} + 2>/dev/null

If plain-crypto-js appears in a lockfile, assume the post‑install script was already executed.

Search for leftover package directories

The malware attempted to self‑delete, but cleanup is not always reliable.

find / -type d -name "plain-crypto-js" 2>/dev/null

Any result here is a strong indicator of execution.

Search the npm cache (important for rebuilt or cleaned repos)

Even if repos were cleaned or rebuilt, npm caches may still retain evidence.

grep -iRl "plain-crypto-js" ~/.npm/_cacache 2>/dev/null

This is particularly useful on:

developer workstations

CI runners

shared build hosts

Search CI / build workspaces

If this ran in CI, the host is often less important than the secrets it had access to.

grep -iRl "plain-crypto-js" /var/lib 2>/dev/null

grep -iRl "plain-crypto-js" /opt 2>/dev/null

grep -iRl "plain-crypto-js" /srv 2>/dev/null

grep -iRl "plain-crypto-js" /home/*/.cache 2>/dev/null

Focus on runners that executed builds during the exposure window.

Search the entire filesystem (slow, last resort)

Use this only if you need maximum coverage and can tolerate long runtimes.

grep -iRl "plain-crypto-js" / 2>/dev/null

How to interpret results

Found anywhere → Assume the system executed the malicious installer → Rotate all credentials and secrets and rebuild affected hosts

Not found → Still review:

CI runners

container images built during the exposure window

other machines using the same repos

Indicators of compromise

The following Indicators of Compromise (IoCs) relate directly to the 31 March 2026 supply‑chain attack in which threat actors hijacked the npm account of Axios’ lead maintainer and published two legitimate‑looking but compromised releases of the package (axios@1.14.1 and axios@0.30.4). During the several‑hour exposure window, any system that executed npm install or npm update could have automatically pulled a malicious dependency, plain‑crypto‑js@4.2.1, which acted as a dropper for OS‑specific implants and connected back to active command‑and‑control infrastructure.

These IoCs represent known network endpoints, malicious file hashes, and package artefacts associated with the attack and should be used to guide detection, threat‑hunting, and remediation efforts. Because the malware attempted to self‑clean and remove forensic traces, the presence of any of the indicators below should be treated as strong evidence of compromise, and the absence of detection should not be interpreted as a clean bill of health.

Network Indicators

  
      Indicator
      Type
      Notes
    
      142.11.206.73
      C2
      WAVESHAPER.V2
    
      sfrclak[.]com
      C2
      WAVESHAPER.V2
    
      http://sfrclak[.]com:8000
      C2
      WAVESHAPER.V2
    
      http://sfrclak[.]com:8000/6202033
      C2
      WAVESHAPER.V2
    
      23.254.167.216
      C2
      Suspected UNC1069 Infrastructure

File Indicators

  
      Family
      Notes
      SHA256
    
      WAVESHAPER.V2
      Linux Python RAT
      fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf
    
      WAVESHAPER.V2
      macOS Native Binary
      92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a
    
      WAVESHAPER.V2
      Windows Stage 1
      617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101
    
      WAVESHAPER.V2
      N/A
      ed8560c1ac7ceb6983ba995124d5917dc1a00288912387a6389296637d5f815c
    
      SILKBELL
      N/A
      e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09
    
      N/A
      system.bat
      f7d335205b8d7b20208fb3ef93ee6dc817905dc3ae0c10a0b164f4e7d07121cd
    
      N/A
      plain-crypto-js-4.2.1.tgz
      58401c195fe0a6204b42f5f90995ece5fab74ce7c69c67a24c61a057325af668

This incident does not behave like a normal vulnerable package. Absence of evidence is not evidence of absence if installs were ephemeral.

Lucy Blight