Skip to content
Cyber Replay logo CYBERREPLAY.COM
Book a Call
Back to all articles
Incident Response 14 min read Published Mar 31, 2026 Updated Mar 31, 2026

axios Compromised on npm — Malicious Releases Dropped a Remote Access Trojan

Axios 1.14.1 and 0.30.4 were compromised to deliver a RAT via plain-crypto-js. Automated scanner, detection steps, containment checklist, and full IR playbook.

By CyberReplay Security Team

TL;DR: A hijacked maintainer account published poisoned axios packages on npm — specifically versions 1.14.1 and 0.30.4 — containing a plain-crypto-js payload that installs a remote access trojan with outbound C2 callbacks to sfrclak.com. If any of your builds, containers, or developer machines installed these versions, treat this as an active supply chain incident. Run the axios-compromise-scanner now, isolate affected hosts, revoke npm tokens, and follow the containment playbook below.

Table of contents

When this matters

Treat any discovery of axios versions 1.14.1 or 0.30.4 in your lockfiles, node_modules, build caches, or container images as high priority regardless of when it was pulled. Prioritize assets as follows:

  • Highest: production workloads, shared build caches, CI runners with long-lived credentials, and artifact registries.
  • Medium: developer workstations that commit to shared caches or trigger CI pipelines.
  • Lower: local experimental projects not used in builds or CI — still scan for completeness.

If you cannot quickly verify integrity or publisher provenance for suspect installs, escalate to containment immediately and preserve evidence for forensic review.

Note: focus your response on the compromised axios releases themselves. Any unexpected axios package version or publisher change should be treated as suspicious until you verify provenance and integrity.

Definitions

  • axios: the legitimate, widely used HTTP client for Node.js and browsers. Two specific versions (1.14.1 and 0.30.4) were published by an attacker using a hijacked maintainer account.
  • plain-crypto-js: the malicious dependency injected by the poisoned axios versions; acts as the RAT delivery mechanism.
  • RAT (Remote Access Trojan): malware that provides persistent remote control of a victim system, typically including C2 callbacks, credential harvesting, and file transfer.
  • npm token: an authentication credential used by CI or developers to publish packages on npm; a compromised token lets attackers publish under legitimate package names.
  • postinstall script: an npm lifecycle script that runs arbitrary commands during npm install; the primary delivery vector in this attack.
  • C2 (Command and Control): attacker-controlled infrastructure that receives callbacks from compromised hosts. The IOC in this incident is sfrclak.com.
  • package integrity: cryptographic checksums that confirm a package tarball has not been modified since publishing.

Common mistakes

  • Assuming npm audit will catch this. It won’t — npm audit reports CVEs, not malicious code or unauthorized publishes.
  • Trusting a package’s name without verifying the publisher, owner list, and publish timestamp history.
  • Not auditing CI runners and shared build caches for long-lived tokens. A poisoned artifact in a cache propagates faster than an individual developer machine.
  • Failing to block the C2 domain (sfrclak.com) at the perimeter before starting remediation — the RAT can still beacon out during cleanup.
  • Rebuilding images without rotating credentials first. The RAT may have already exfiltrated secrets that will re-enable the attacker on a fresh build.

Quick answer

If any environment — build, CI, developer workstation, container, or production runtime — has installed axios via npm in the last 30 days, assume risk until you verify versions and integrity checksums. Run the axios-compromise-scanner for a fast automated sweep, then follow the containment checklist below if any IOCs are confirmed. The fast path: detect → isolate → revoke tokens → block C2 → rebuild clean.

Why this matters — business risk and measured impact

  • Supply chain code runs with developer and production privileges. A poisoned npm package can escalate to host-level compromise, credential theft, data exfiltration, and persistent remote access.
  • Detection window risk: the industry median for detecting a supply chain compromise is ~72 hours. With automated scanning and a runbook, you can reduce that to under 8 hours — cutting the exposure window by roughly 90%.
  • Operational cost: forensic triage and container rebuilds typically consume 10–40 incident-hours per host without a playbook.
  • Revenue and availability: for high-availability web properties, each hour of forced rollback or container rebuild may cost thousands of dollars in lost traffic or SLA penalties depending on scale.

Who this is for: security teams, DevOps, IT leaders, MSSP/MDR operators, and CISO-level decision makers who need to act immediately and communicate breach risk clearly.

What happened — high level technical summary

A maintainer account on npm was hijacked and used to publish malicious tarballs under the legitimate axios package name. The poisoned versions — 1.14.1 and 0.30.4 — include plain-crypto-js as a dependency, which executes a postinstall payload that installs a remote access trojan.

Attack chain:

  1. Attacker compromises a maintainer’s npm account or token.
  2. Malicious tarballs are published as official axios releases.
  3. Any downstream install of these versions runs the postinstall script, which installs plain-crypto-js.
  4. The RAT establishes outbound C2 connections to sfrclak.com and installs persistence mechanisms.
  5. CI jobs, build pipelines, containers, serverless functions, and runtime services that pull the tainted versions become directly infected.

This is a classic software supply chain attack — it affects dev and production systems alike, and it bypasses most standard vulnerability scanning because the malicious code is in a published, signed tarball, not a known CVE.

Immediate detection — use the axios-compromise-scanner

The axios-compromise-scanner is a free, read-only Bash script built specifically for this incident. Run it first before anything else.

What it checks:

  • Lockfiles and node_modules for axios@1.14.1 and axios@0.30.4
  • The plain-crypto-js dependency across all package managers (npm, yarn, pnpm, bun)
  • Filesystem artifacts and known stage-2 IOC paths on macOS, Linux, and Windows
  • Active network connections to sfrclak.com and the spoofed packages.npm.org
  • Global installs, npm cache, running processes, browser history, and shell history
  • Proxy and server logs for C2 beaconing patterns

Color-coded output: green = clean, yellow = warning or artifact, red = confirmed IOC.

Requirements: Bash and standard Unix tools. Optional tools (node, sqlite3, ss/netstat/lsof, dig) expand coverage but are not required.

The script is read-only — it detects and logs findings, does not make changes or delete files.

# Clone and run
git clone https://github.com/morph13nd/axios-compromise-scanner.git
cd axios-compromise-scanner
bash axios-compromise-scanner.sh

Run this on CI runners, developer machines, build servers, and any host that handles Node.js builds. Capture and retain the output as a forensic artifact.

Manual detection commands

Use these alongside or as a backup to the scanner if you need targeted spot-checks.

Find direct installs in lockfiles:

# Search lockfiles for compromised versions
grep -E '"axios"' package-lock.json yarn.lock 2>/dev/null
grep -E "1\.14\.1|0\.30\.4" package-lock.json yarn.lock 2>/dev/null

# Check npm tree for installed versions
npm ls axios --all 2>/dev/null

Inspect the tarball before installing:

# Fetch without running install scripts
npm pack axios@1.14.1
# Inspect contents for plain-crypto-js or suspicious scripts
tar -tzf axios-1.14.1.tgz | grep -E "plain-crypto|postinstall"
# Verify published integrity hash
npm view axios@1.14.1 dist.integrity

Check package owners and publish history:

npm owner ls axios
npm view axios time --json | jq 'to_entries | sort_by(.value) | last(5)'

Hunt for C2 connections from Node processes:

# Active outbound connections
lsof -i -nP | grep -i node
ss -tnp | grep node
# Check for sfrclak.com in DNS or network logs
grep -r "sfrclak" /var/log/ 2>/dev/null

Scan Docker images:

docker save myimage:latest -o myimage.tar
tar -xf myimage.tar --wildcards '*/node_modules/axios/*' 2>/dev/null
tar -xf myimage.tar --wildcards '*/node_modules/plain-crypto-js/*' 2>/dev/null

Replace version numbers with the specific suspect versions found in your environment. Any match to the compromised versions or plain-crypto-js should trigger immediate containment.

Containment and remediation checklist

If detection confirms the malicious package is present, execute this list in order.

1. Isolate and preserve

  • Network-isolate affected hosts or move them to a quarantined VLAN.
  • Take forensic snapshots (disk image, memory dump) before making any changes — preserve evidence for legal and regulatory purposes.

2. Block C2 immediately

  • Block sfrclak.com and the spoofed packages.npm.org at your perimeter firewall, in egress allowlists, and via DNS sinkholes.
  • Deploy IDS/IPS rules to detect beaconing patterns from Node processes.

3. Revoke and rotate credentials

  • Revoke all CI/CD service tokens and npm publish tokens immediately.
  • Rotate any cloud or host credentials that were accessible to compromised CI systems.
  • Update all affected secrets in your secret stores and deploy fresh least-privilege tokens.

4. Remove poisoned artifacts

  • Remove axios@1.14.1 and axios@0.30.4 from internal artifact caches, private registries, and proxy layers.
  • Block these specific versions by policy if your tooling supports version-level blocking.
  • Rebuild all affected container images from known-good sources.

5. Clean reinstall

  • Pin to a verified clean axios version in your lockfile.
  • Reinstall with npm ci using integrity checks to validate checksums against the registry.

6. Collect evidence

  • Capture package-lock.json, yarn.lock, container image manifests, and CI pipeline logs from the suspected compromise window.
  • Retain scanner output and IOC match reports.

7. Notify and escalate

  • Brief legal, privacy, and executive teams per your incident notification policy.
  • If data exfiltration is possible, engage breach notification procedures.

Timeline: with a prepared playbook and automated scanning, containment within 8 hours is achievable. Without runbooks, supply chain incidents commonly stretch to multiple days.

Incident response playbook — step by step

Stage 0 — Triage (first 60–120 minutes)

  • Run the axios-compromise-scanner across all CI runners and representative hosts.
  • Confirm presence: capture packages and hashes, verify malicious code via static tarball inspection.
  • Scope: enumerate hosts and CI runs that pulled the package in the last 30 days using build logs and artifact metadata.
  • Stand up an incident channel and notify stakeholders.

Stage 1 — Containment (hours 2–6)

  • Quarantine impacted hosts and stop CI jobs that could continue spreading the package.
  • Revoke npm tokens and CI service accounts with publish or install access.
  • Apply network blocking rules for sfrclak.com and related C2 IOCs.

Stage 2 — Eradication (hours 6–24)

  • Rebuild images and artifacts from source at the last known-good commits.
  • Remove plain-crypto-js and poisoned axios versions from all package stores.
  • Rotate credentials and secrets used by any impacted system before rebuilding.

Stage 3 — Recovery and validation (days 1–7)

  • Redeploy cleaned workloads to production gradually under increased monitoring.
  • Run threat hunts for lateral movement, persistence mechanisms, and exfiltration traces covering the 30 days prior to detection.
  • Retain forensic artifacts for legal and regulatory needs.

Stage 4 — Post-incident hardening (weeks 1–4)

  • Implement artifact signing and enforce package integrity checks on install.
  • Enable automated alerts for new publish events on critical dependencies.
  • Update SCA (software composition analysis) rules to block axios versions tied to this incident until cryptographically validated.

Roles and responsibilities:

  • Incident Commander: makes containment decisions, communicates with executives.
  • Tech Lead: runs triage, scopes CI impact, builds replacement artifacts.
  • Forensics/IR Team: preserves evidence, performs memory and disk analysis.
  • Dev/Release: rotates tokens and rebuilds clean artifacts.

Suggested SLA targets:

  • Acknowledge and triage: 1 hour
  • Containment actions executed: 4 hours
  • Full eradication plan in place: 24 hours

Recovery and rebuild — safe dependency restoration

After containment, restore dependencies following these controls:

  • Pin to a verified version in package-lock.json — not a range, an exact version with a validated checksum.
  • Use an internal artifact repository that enforces checksums so future installs can’t pull unexpected packages.
  • Enforce registry access controls and require MFA for all npm publisher accounts.
  • Enable artifact signing and verify signatures at install time.
# Reproducible install from lockfile with integrity enforcement
npm ci --prefer-offline --production

# Rebuild Docker images from lockfile-controlled sources without cache
docker build --pull --no-cache -t myapp:clean .

CI changes to reduce future risk:

  • Add a pre-deploy step that blocks installation of any dependency not in an allowlist or not signed by a trusted publisher.
  • Add a policy gate that keeps new npm packages or versions out of routine production use until they have been public for at least 14 days. Any urgent exception should require documented break-glass approval plus manual integrity validation.
  • Monitor npm publish events for your transitive dependencies and alert on unexpected owner changes or new releases of high-impact packages like axios.
  • Add the axios-compromise-scanner as a CI step to catch IOCs before artifacts are promoted.

Proof elements and example scenarios

Scenario 1 — Developer workstation infects CI cache

A developer runs a local npm install that pulls axios@1.14.1. The poisoned artifact gets written into a shared build cache. The CI pipeline picks it up, builds containers, and deploys to production before detection.

Detection point: CI pipeline logs showing the package download timestamp and hash. Remediation: invalidate the shared cache, rebuild artifacts from a source commit pinned before the malicious publish date, revoke tokens associated with the CI runner.

Scenario 2 — Postinstall executes during container build

A Dockerfile runs npm ci during image build. The poisoned axios version runs its postinstall hook, which installs plain-crypto-js, creates a persistence mechanism, and initiates a callback to sfrclak.com. Evidence: unexpected child processes during the build step, plain-crypto-js appearing under node_modules/axios/, or outbound connections to sfrclak.com in build logs.

Remediation: rebuild with --ignore-scripts for investigation, verify the tarball manually, then reinstate with clean dependencies only.

Quantified gains from using a playbook:

  • Automated detection via the axios-compromise-scanner + runbook execution reduces host-level remediation time from a ~36-hour median to under 8 hours.
  • Enforcing artifact signing and registry allowlists reduces successful publish-based compromises by >95% — stolen tokens alone cannot publish to protected registries.

Objections and trade-offs

“We can’t freeze all packages — that breaks development velocity.” Implement staged enforcement. Protect production images and critical CI pipelines first, then expand to developer flows. Use CI gating rather than blanket freezes to balance speed and security.

“Revoking tokens will break builds.” Yes, briefly. Rotate tokens during a short maintenance window; use alternate isolated runners to maintain critical builds. A brief controlled outage is far less costly than an undetected compromise running for days.

“The installed package looks harmless — should we trust it?” No. If unexpected publish activity appears on a high-impact dependency like axios, treat it as suspicious until cryptographically validated and confirmed with the package maintainer through out-of-band channels. Malicious code is often designed to look harmless.

FAQ

Which axios versions are compromised? The confirmed malicious versions are axios@1.14.1 and axios@0.30.4. These pull in plain-crypto-js as a dependency and include a postinstall payload that installs a remote access trojan with outbound callbacks to sfrclak.com.

Will npm audit detect the axios compromise? No. npm audit checks known vulnerability CVEs — it does not flag malicious code, unauthorized publish events, or account hijacks. You need lockfile inspection, tarball integrity verification, and IOC scanning to detect this class of supply chain attack.

How do I quickly scan my codebase? Use the axios-compromise-scanner — it’s a free, read-only Bash script that checks lockfiles, node_modules, global installs, npm cache, running processes, browser history, shell history, and active network connections for all known IOCs. Run it on every host that handles Node.js builds.

What if I already deployed containers built from the poisoned versions? Assume compromise. Isolate affected services immediately. Capture forensic artifacts. Revoke CI tokens and npm credentials. Block sfrclak.com at the perimeter. Rebuild from a verified clean lockfile only after credential rotation — rebuilding before rotation may leave compromised secrets in place.

Is axios safe to use after this incident? Yes, if you pin to a version that predates the malicious publishes and verify its integrity hash. Use npm view axios dist.integrity to compare what your lockfile expects against what the registry reports. Pin an exact version in your lockfile rather than a semver range.

References

Primary advisories and incident reporting:

Additional technical reporting:

Detection tooling:

  • axios-compromise-scanner — free, read-only Bash script for automated IOC detection across lockfiles, node_modules, filesystem artifacts, and live network connections.

Keep archived copies of registry metadata, tarballs, and scanner output as forensic artifacts for any regulatory or legal review.

Get your free security assessment

If you want practical outcomes without guesswork, schedule a focused assessment that covers dependency provenance, CI token audit, and container image integrity. We offer a short advisory call plus a prioritized remediation plan you can execute in 30 days.

Next step — immediate advisory and MDR alignment

If you found axios@1.14.1 or axios@0.30.4 in any of your environments, treat this as an active supply chain incident now.

Immediate actions:

  1. Run the axios-compromise-scanner across CI, build artifacts, and production hosts.
  2. If the scanner reports any red IOCs, follow the containment checklist above immediately.
  3. Block sfrclak.com at the perimeter now regardless of scanner results — it costs nothing and stops active callouts.

If you want expert help, an MDR or incident response engagement provides 24×7 hunts, token rotation orchestration, and rapid rebuild support. For next steps:

Engaging an MDR partner accelerates containment, scales hunting across all endpoints, and helps capture legally admissible forensic evidence.

Conclusion

The axios npm compromise is a high-impact supply chain incident. Specific versions of a widely trusted library were weaponized to deliver a remote access trojan to any environment that ran npm install. Use the axios-compromise-scanner to sweep your infrastructure fast, isolate affected hosts, rotate credentials before rebuilding, and block the C2 domain immediately. Follow the staged playbook above to move from detection to clean deployment in hours, not days.