Axios Compromised on npm: How 1.14.1 and 0.30.4 Dropped a Cross-Platform RAT

Axios is one of the most trusted packages in the JavaScript ecosystem. On March 31, 2026, that trust path broke.

StepSecurity disclosed that malicious npm releases axios@1.14.1 and axios@0.30.4 pulled a hidden dependency, plain-crypto-js@4.2.1, whose postinstall script fetched a cross-platform remote access trojan. An axios GitHub issue documenting the compromise was opened the same day.

The short answer: if a developer laptop or CI runner installed either version during the exposure window, treat it as a potential host compromise, not just a bad library update.

What makes this incident unusually serious is that the attacker did not need obvious malicious changes across the Axios codebase. According to StepSecurity’s diff analysis, the attack path was built around publish credentials, dependency injection, install-time execution, and anti-forensics cleanup.

AXIOS COMPROMISE AT A GLANCE

100M+

Weekly Downloads

Axios reach cited by StepSecurity

2

Poisoned releases

1.14.1 and 0.30.4

< 3 hrs

Exposure window

before npm pulled axios versions

3

Target OSes

macOS, Windows, Linux

READ THE SECTION THAT MATCHES YOUR JOB

This incident means different things depending on whether you own applications, incident response, or package publishing.

Use this to skip to what matters

NODE TEAMS

You need the affected versions and triage checks

Start with TL;DR, then jump to the detection section and first-hour checklist.

Focus on

Affected versionsHow to check lockfiles and hostsImmediate containment

OutcomeYou will know whether your project needs a normal dependency fix or full incident response.

SECURITY TEAMS

You need the kill chain and IOCs

Focus on the timeline, how the dropper worked, and the platform-specific artifacts.

Focus on

TimelineC2 and file indicatorsRebuild and secret rotation logic

OutcomeYou will have a cleaner technical narrative for triage, forensics, and stakeholder updates.

PACKAGE MAINTAINERS

You need the release-pipeline lesson

Read the provenance section and maintainer guidance after the incident summary.

Focus on

Trusted publishing2FA and token policyRelease metadata drift

OutcomeYou will see why package security now depends as much on publish-path hardening as code review.

TL;DR

• The malicious Axios versions were 1.14.1 and 0.30.4, published on March 31, 2026.
• According to StepSecurity, both releases injected plain-crypto-js@4.2.1, a dependency not used anywhere in Axios source code.
• The malicious package ran a postinstall hook that contacted the attacker’s infrastructure and pulled platform-specific payloads for macOS, Windows, and Linux.
• StepSecurity says the malware then rewrote its own package.json to look clean, which means naive post-incident inspection can miss what happened.
• StepSecurity’s March 31 timeline says npm later unpublished the bad Axios versions and reverted latest to 1.14.0.
• If plain-crypto-js exists in node_modules at all, that is already suspicious, because legitimate Axios releases do not depend on it.
• If a developer machine or runner installed the bad versions and had secrets available, rotate credentials and rebuild from known-good state.
• The larger lesson is about release provenance: npm’s own docs recommend trusted publishing with OIDC because it removes the reusable token risk that attacks like this exploit.

Source: StepSecurity technical analysis published on March 30-31, 2026.

What happened to Axios on npm?

The verified story starts on March 30, 2026 and unfolds quickly.

StepSecurity says the attacker first seeded a lookalike dependency, then published the poisoned Axios versions just after midnight UTC on March 31. The packages were removed within hours, but the short exposure window does not make the incident low risk. An install-time payload only needs one successful run.

1. 2026-03-30 05:57 UTC

   Decoy package seeded

   StepSecurity says `plain-crypto-js@4.2.0` was published first as a clean decoy to create registry history.

2. 2026-03-30 23:59 UTC

   Malicious dependency goes live

   `plain-crypto-js@4.2.1` added the `postinstall` hook and the obfuscated dropper.

3. 2026-03-31 00:21 UTC

   Axios 1.x branch poisoned

   StepSecurity says `axios@1.14.1` was published from the compromised maintainer account.

4. 2026-03-31 01:00 UTC

   Axios 0.x branch poisoned

   `axios@0.30.4` followed 39 minutes later, expanding coverage to older installations.

5. 2026-03-31 03:15 UTC

   Bad Axios versions removed

   StepSecurity inferred the unpublish timing from registry metadata and says `latest` reverted to `1.14.0`.

6. 2026-03-31 04:26 UTC

   Security-holder stub replaces dependency

   npm replaced `plain-crypto-js` with a security-holder package, ending the live install path.

The exact dates matter here. The bad Axios releases were live on March 31, 2026, not for days or weeks, but for a long enough window to compromise any machine that installed them.

Why this attack was worse than a normal bad patch release

WHY THIS INCIDENT IS HARD TO SPOT

The danger came from how little had to change for the attacker to get code execution on install.

MINIMAL DIFF

Axios source barely changed

StepSecurity says the meaningful change was the dependency manifest, not a broad library rewrite.

• Low visual noise in package diff
• Easy to miss in semver patch churn
• No obvious malicious import inside Axios code

PHANTOM DEPENDENCY

The added package existed only to run `postinstall`

StepSecurity says `plain-crypto-js` was never imported anywhere in Axios. Its job was execution, not functionality.

• Runtime dependency with zero usage
• Install-time code execution
• Hidden behind normal npm resolution

ANTI-FORENSICS

The malware tried to look clean after it ran

StepSecurity says the dropper replaced its own manifest with a clean decoy so version checks could mislead responders.

• `package.json` rewritten after execution
• Version spoofing toward 4.2.0
• Naive `npm list` checks become unreliable

OPERATIONAL PREP

Payloads were staged for three operating systems

The attacker had macOS, Windows, and Linux behavior ready before the bad Axios versions went live.

• Cross-platform reach
• Live C2 infrastructure
• A short exposure window still creates real damage

The deeper lesson is that package trust is not only about reviewing source files anymore. It is about verifying who published the package, how it was published, what changed in the dependency graph, and what happens during install.

How the kill chain actually worked

THE FOUR-STEP KILL CHAIN

This was a release-path compromise designed to survive shallow review and move fast before defenders reacted.

1. 1

   STEP 01

   Maintainer access was abused

   StepSecurity says both malicious Axios versions were published from the legitimate maintainer account `jasonsaayman`, whose email was changed to `ifstap@proton.me`.

   • The package still looked authentic at first glance
   • The version numbers fit normal semver expectations
   • Trust in the maintainer identity did the first layer of social engineering

   Why this step existsAttackers did not need a fake package name for Axios itself because they had a real publish path.

2. 2

   STEP 02

   A decoy dependency was staged in advance

   The attacker first published a clean `plain-crypto-js@4.2.0`, then upgraded it to `4.2.1` with the malicious `postinstall` hook.

   • Registry history made the package look less suspicious
   • The package copied crypto-js metadata to look familiar
   • The attack was prepared before Axios was touched

   Why this step existsThis reduced the chance that defenders would dismiss it immediately as a brand-new throwaway package.

3. 3

   STEP 03

   Axios was republished with one hidden dependency

   StepSecurity says the compromised releases added `plain-crypto-js@^4.2.1` to `dependencies`, even though Axios never imported it.

   • The dependency graph changed
   • The application code barely changed
   • Any install automatically pulled the weaponized package

   Why this step existsThe attack moved from registry metadata to install-time execution without needing runtime app logic.

4. 4

   STEP 04

   The dropper fetched malware, then tried to erase the signal

   StepSecurity says the `postinstall` script contacted the C2, delivered platform-specific payloads, and then replaced its manifest with a clean-looking stub.

   • C2 domain: `sfrclak.com`
   • Linux artifact: `/tmp/ld.py`
   • Self-cleaning behavior after payload launch

   Why this step existsBy the time many teams would inspect `node_modules`, the most obvious artifact had already been rewritten.

Clean Axios vs the compromised releases

How do you check whether your team was exposed?

Start with the version check, but do not stop there.

npm ls axios 2>/dev/null | grep -E '1.14.1|0.30.4'
grep -R "plain-crypto-js" package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null
test -d node_modules/plain-crypto-js && echo "POTENTIALLY AFFECTED"

The presence of node_modules/plain-crypto-js is especially important. StepSecurity says legitimate Axios versions never install it, and the malware rewrites its own manifest after execution, so the directory itself is a stronger signal than the displayed version string.

Then check for platform artifacts StepSecurity published:

# macOS
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null

# Linux
ls -la /tmp/ld.py 2>/dev/null

For Windows, StepSecurity lists %PROGRAMDATA%\wt.exe, %TEMP%\6202033.vbs, and %TEMP%\6202033.ps1 as relevant artifacts. The same report also lists the network indicators sfrclak.com and 142.11.206.73.

Source: StepSecurity Harden-Runner runtime validation and file event capture.

What should teams do in the first hour?

StepSecurity’s remediation guidance on March 31 was to pin back to clean versions, remove the malicious dependency, and treat any machine with the dropper as compromised. In practical terms, the first hour should look like this:

FIRST-HOUR RESPONSE CHECKLIST

Track progress as you work through the list

0%

0/6 done

• Pin Axios back to the clean line StepSecurity recommended on March 31: `1.14.0` for 1.x or `0.30.3` for 0.x, then regenerate lockfiles from a clean machine. critical
• Search repos, lockfiles, CI logs, and developer machines for `1.14.1`, `0.30.4`, and `plain-crypto-js`. critical
• Isolate and rebuild any runner or laptop that installed the bad versions while secrets were available. critical
• Rotate npm tokens, cloud credentials, SSH keys, CI secrets, and sensitive `.env` values exposed on affected systems. critical
• Block egress to `sfrclak.com` and `142.11.206.73` while triage is still active. high
• Use `npm ci --ignore-scripts` in CI jobs where install hooks are not actually required. medium

What package maintainers should change after this

RELEASE PIPELINE LESSONS

The fix is not just 'review package diffs harder.' It is 'make the release path much harder to abuse.'

DO THIS NOW

Harden the publish path itself

npm documentation recommends trusted publishing with OIDC for CI/CD, and it separately documents a stricter package-level setting that requires 2FA and disallows tokens.

• Use trusted publishing where your release automation supports it
• Review whether high-value packages should require 2FA and disallow tokens
• Alert on releases without matching provenance, `gitHead`, or repository tags
• Diff new runtime dependencies against real imports before publishing

For critical packages, release metadata deserves the same scrutiny as source-code changes.

DO NOT ASSUME

Semver-looking patch releases are not safe by default

This incident shows how little has to change for install-time compromise to happen at scale.

• A small `package.json` diff can be more dangerous than a large source diff
• A quick unpublish does not erase host-level compromise
• Lockfile checks alone can miss postinstall anti-forensics
• Manual publishes that break normal automation should trigger immediate review

If release provenance suddenly drifts, assume compromise until proven otherwise.

The official npm guidance is unusually relevant here. npm says to prefer trusted publishing with OIDC for CI/CD because it eliminates the security risks tied to long-lived publish credentials. npm also documents a stricter package setting, “Require two-factor authentication and disallow tokens”, for cases where interactive publishing is acceptable and tokenless safety is worth the operational tradeoff.

FAQ

Questions readers usually have

These are the questions engineering teams and search users are most likely to ask after hearing that Axios was compromised.

Versions

Which Axios versions were compromised?

+

Attack path

Was Axios source code itself backdoored?

+

Forensics

How can `plain-crypto-js` look clean after infection?

+

Status

Is Axios safe to use now?

+

Prevention

Why does trusted publishing matter in this incident?

+

Primary sources

• StepSecurity technical incident analysis
• Axios GitHub issue #10604
• npm docs: using trusted publishing in CI/CD
• npm docs: requiring 2FA and disallowing tokens for package publishing