The Axios Supply Chain Attack: Analyzing the plain-crypto-js NPM Malware

Isha Sangpal

— 8 min read
The Axios Supply Chain Attack: Analyzing the plain-crypto-js NPM Malware

In modern JavaScript development, a handful of libraries are so widely adopted that they become part of the “default stack.” axios is one of those rare dependencies: a standard HTTP client used across Node.js backends, front-end web apps, CI pipelines, and internal tooling. With usage at massive scale, it is not “just another npm package.” It is infrastructure.

That is why reports of a compromised axios release should be treated as an emergency, not a routine security advisory. Multiple security teams and outlets have described an active compromise in which a malicious axios version pulls in an unfamiliar dependency, plain-crypto-js@4.2.1, acting as an obfuscated dropper designed to deliver a cross-platform Remote Access Trojan (RAT). The risk is not theoretical. The impact surface includes developer machines, build systems, and potentially production environments.

This article explains how such an attack works, why it is so effective, what the malware is trying to achieve, and how security and engineering teams should respond immediately and responsibly.

Supply chain attacks succeed because they exploit something teams must do to ship software: reuse. The npm ecosystem is built for speed and composability, but that same convenience creates a unique security asymmetry:

  • A single compromised package can reach thousands of organizations quickly.
  • “Trusted” dependencies rarely receive the same scrutiny as first-party code.
  • Installation happens automatically in many environments.
  • The blast radius extends beyond the app into CI/CD, developer endpoints, and secrets stores.

In plain terms: when a foundational package gets compromised, the attacker inherits the trust relationship between that package and everyone who installs it.

How It Happened: Identity Compromise vs. Code Exploitation

A common misconception is that major open-source compromises happen because attackers find a vulnerability in the project’s code. In many cases, including the scenario described here, the weak point is not the repository. It is the human publishing pipeline.

Incident reporting indicates the attackers did not exploit axios functionality itself. Instead, they hijacked npm publishing access belonging to a maintainer. Even when a registry enforces 2FA for high-impact packages, identity-based bypass techniques are now well understood and widely used, including:

  • Session token theft, obtained through phishing or reverse-proxy credential capture methods.
  • Compromise of local developer machines, including theft of configuration artifacts such as ~/.npmrc.
  • Abuse of already-authenticated publishing sessions.

Once the attacker controls a legitimate publishing token or session, the registry accepts the release as authentic. That is what makes these incidents so damaging: the ecosystem’s trust mechanism is working as designed, but it has been pointed at the wrong person.

The Core Technique: Dependency Poisoning via plain-crypto-js

Rather than embedding obvious malicious code directly inside the axios source, the described compromise uses a subtler strategy: dependency poisoning.

The compromised package release updates its package.json to include a new dependency:

  • A dependency name that looks plausible.
  • A version that installs cleanly.
  • A payload that activates during installation or runtime.
{
  "name": "axios",
  "version": "1.14.1",
  "dependencies": {
    "follow-redirects": "^1.15.6",
    "form-data": "^4.0.0",
    "proxy-from-env": "^1.1.0",
    "plain-crypto-js": "^4.2.1" 
  }
}

This technique provides several advantages to an attacker:

  1. Reduced immediate scrutiny: Many reviewers scan diffs for suspicious code changes. A new dependency may not trigger the same alarm.
  2. Automatic distribution: Any environment that resolves the compromised version pulls the new dependency during npm install.
  3. A cleaner separation of roles: axios becomes the “delivery vehicle.” The injected dependency becomes the “payload loader.” Even if one is detected, the attacker can iterate on the other.

In this case, plain-crypto-js is described as not actually performing cryptographic work. It functions as an installer-stage dropper for a RAT.

Inside the Malware: Anatomy of the Cross-Platform RAT

Security analysis outlined in the page breaks the compromise into three phases: evasion, dropping, and command & control. This is a classic structure for malware designed to survive basic scanning and move quickly toward persistent access.

Phase 1: Runtime Deobfuscation (Evasion)

A lot of security tooling in build pipelines still relies on pattern matching. That is not inherently bad, but it is easy to bypass when the attacker knows what strings defenders search for.

Instead of plainly writing:

  • require('child_process')
  • execSync(...)
  • require('fs')

…an obfuscated dropper can reconstruct those module names dynamically in memory. 

// Instead of require('child_process'), the malware decodes it at runtime:
const b64 = "Y2hpbGRfcHJvY2Vzcw=="; 
const mod = Buffer.from(b64, 'base64').toString('ascii');
const dynamicExec = global['req' + 'uire'](mod).execSync;

The key idea is simple: static analysis cannot match what it cannot see.

This matters because many organizations treat “no obvious malicious strings found” as a proxy for safety. Attackers know that. Obfuscation is not just to confuse humans, it is to defeat automated policy gates.

Phase 2: Cross-Platform Payload Staging

After preparing the execution environment, the malware reaches out to attacker-controlled infrastructure. According to the analysis referenced, it detects the host OS and downloads a platform-appropriate binary payload.

It also chooses directories that are convenient for attackers and painful for defenders:

  • Linux/macOS: locations under /tmp or /var/tmp
  • Windows: locations such as C:\\ProgramData\\ or %TEMP%

These paths are common because:

  • They often have permissive write access.
  • Activity there is noisy and easy to blend into.
  • Many organizations do not monitor temp directories with the same rigor as system or application directories.
  • They are frequently used by legitimate installers and build tools, which gives the attacker cover.

Phase 3: RAT Execution and Anti-Forensics

The payload described is a Golang-based RAT that, once executed, establishes a persistent connection to command-and-control (C2), reportedly using WebSocket communications.

At the same time, the dropper performs anti-forensics: removing or renaming artifacts to reduce the evidence footprint. This is another detail that separates nuisance malware from a targeted capability. The attacker is not only trying to get in. They are trying to ensure the compromise is hard to prove and hard to triage.

The Real Blast Radius: Assessing Your Exposure

A key message in the page is that if axios@1.14.1 (as described) executed anywhere in your environment, you should treat the affected host as compromised. That’s not alarmism. It reflects how modern development environments are wired.

1) Developer Workstations

A developer machine often contains the highest-value assets in an organization:

  • SSH keys and known_hosts
  • Git credentials
  • Cloud credentials or cached tokens
  • .env files and local secrets
  • Source code and proprietary logic
  • Access to internal dashboards and staging environments

If a RAT lands on a developer endpoint, the attacker can pivot quietly, impersonate trusted access, and move laterally.

2) CI/CD Pipelines

CI is frequently the most dangerous place to execute untrusted code because it has:

  • Non-interactive secret access
  • Signing keys, deployment tokens, package publishing credentials
  • Network access to internal build services and registries
  • The ability to produce production artifacts

If malicious code runs during npm install inside CI, attackers may gain what they need to compromise releases downstream, turning a single incident into an ongoing propagation event.

3) Production Servers

In mature environments, production should be immutable: artifacts are built once and deployed without reinstalling dependencies at runtime. But many real systems still run npm install during deployment, image build, or post-deploy steps. If that happens with an affected version, the RAT may execute directly on servers that process live traffic, giving the attacker a foothold behind perimeter defenses.

Remediation

When supply chain incidents occur, speed matters, but so does discipline. The goal is to stop spread, identify exposure, and prevent recurrence without destroying evidence you still need.

Freeze and Audit Lockfiles

Start by locating where plain-crypto-js appears in lockfiles across repositories. The provided command searches common lockfile formats:

  • package-lock.json
  • yarn.lock
  • pnpm-lock.yaml
find . -name "package-lock.json" -o -name "yarn.lock" -o -name "pnpm-lock.yaml" | xargs grep -l "plain-crypto-js"

If you find it, treat that repository and any machine that installed dependencies from it as potentially exposed.

Make sure you include:

  • Developer laptops and workstations
  • CI agents and runners
  • Build containers and cached dependency volumes
  • Any automated build jobs that might have auto-upgraded

Pin to a Known-Good axios Version

One of the most actionable lessons here is the danger of permissive semver operators in high-trust dependencies. If your package.json uses ^ or ~, an attacker only needs to compromise a compatible version range to land in your environment.

Strict pinning prevents accidental uptake of compromised versions:

  • Replace ^1.x.x with an exact version known to be safe in your environment.
// VULNERABLE (Allows auto-upgrade to the compromised 1.14.1)
"dependencies": {
  "axios": "^1.14.0" 
}

// SECURE (Strictly pinned to a safe version)
"dependencies": {
  "axios": "1.14.0" 
}
  • Rebuild lockfiles under controlled conditions.
  • Prefer reproducible builds that fail if the dependency graph changes unexpectedly.

Hunt with Behavioral IoCs

The IoCs highlighted are practical because they focus on behavior rather than just hashes:

  • Suspicious child processesInvestigate cases where node or npm spawns shells or scripting engines:In many normal npm installs this should be rare, and it is often a strong signal when it appears unexpectedly.
    • cmd.exe, powershell.exe on Windows
    • /bin/sh, /bin/bash on Linux/macOS
  • Outbound network traffic to suspicious domainsMonitor for unusual outbound requests from build agents or developer endpoints during install windows. Correlate spikes with dependency installation events.
  • Temp directory executionWatch for binaries created and executed from /tmp, /var/tmp, %TEMP%, and C:\\ProgramData\\ shortly after npm install events.

Treat Confirmed Execution as a Full Compromise

If you have evidence that the malicious version executed:

  • Rotate credentials that may have been present on the host:
    • Cloud keys (AWS, GCP, Azure)
    • GitHub PATs and deploy keys
    • CI secrets and signing keys
    • Database passwords and service tokens
  • Do not rely on “cleaning” as the primary remediation step.
  • Reimage affected endpoints and rebuild CI runners from known-good baselines.
  • Verify integrity of artifacts produced during the exposure window.

This is painful, but it is often the only defensible posture when a remote access tool may have had time to act.

Future Hardening: Defending the NPM Supply Chain

You cannot eliminate supply chain risk, but you can make it much harder for an attacker to convert a single compromised release into a widespread incident.

1) Enforce Reproducible Dependency Graphs

  • Use lockfiles consistently.
  • Treat lockfile diffs as a security-sensitive change.
  • Consider policies that block builds if the dependency tree changes unexpectedly.

2) Reduce Trust in Install-Time Execution

Many attacks succeed through install scripts and lifecycle hooks. Mitigations include:

  • Restricting or auditing lifecycle scripts in CI.
  • Running installs in sandboxes with least privilege.
  • Using hardened build images that do not contain long-lived credentials.

3) Improve Behavioral Monitoring, Not Just Static Scanning

Obfuscation defeats simplistic regex rules. Supplement with:

  • Runtime telemetry
  • Process tree monitoring for build agents
  • Endpoint detection controls that flag unusual behavior during install windows

4) Secure Maintainer and Publisher Identities (Where You Control Them)

If your organization publishes packages:

  • Protect publishing accounts with phishing-resistant authentication where possible.
  • Lock down token handling and limit token scope.
  • Monitor for unusual publish activity and enforce human review for release events.

Conclusion

The most important takeaway is not the name of the compromised package. It is the shape of the attack:

  • Compromise an identity.
  • Introduce a malicious dependency.
  • Obfuscate to evade scanners.
  • Drop a cross-platform payload.
  • Establish persistent control.
  • Clean up traces.

This pattern will repeat, because it works. Defenses that rely solely on “trusted package = safe package” are no longer sufficient. The most resilient organizations will be the ones that assume compromise is possible, limit the damage a single dependency can cause, and respond with speed and rigor when the ecosystem is under attack.

If your teams develop with Node.js, treat incidents like this as a test of your organizational readiness: dependency governance, CI hardening, endpoint visibility, and incident response discipline. Those capabilities determine whether a supply chain compromise becomes a contained event or a long-term breach.

Resources for Further Research

Read more