Skip to content
בס״ד
Cyber Replay logo CYBERREPLAY.COM
Book a Call
Back to all articles
Security Operations 14 min read Published Mar 30, 2026 Updated Mar 30, 2026

axios Compromised on npm - Malicious Releases Dropped Remote Access Trojan

Axios packages on npm were poisoned to drop a remote access trojan. Practical detection, containment, and incident playbook for ops and leadership.

By CyberReplay Security Team

TL;DR: A hijacked maintainer account published poisoned axios packages on npm that install a remote access trojan. If you use axios in any builds or containers, treat this as a supply chain incident: detect installations, isolate impacted systems, revoke credentials, and run a focused hunt for remote access indicators. Follow the checklist below to reduce exposure from days to hours and to preserve evidence for recovery and liability management.

Table of contents

When this matters

When this matters: treat any unexpected version or publisher change for “axios” as high priority if the package was pulled into build systems, CI artifacts, container images, or production runtimes within the last 30 days. Prioritize teams and 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 PRs that trigger CI.
  • Lower: local experimental projects not used in builds or CI but still scan for discovery.

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

Definitions

  • axios: the legitimate widely used HTTP client for Node.js and browsers. In this incident, attackers published malicious axios releases that must be treated as compromised artifacts.
  • Compromised: an account, token, or system that an attacker controls or uses to publish artifacts, execute code, or access secrets without authorization.
  • RAT (Remote Access Trojan): malware that provides persistent remote control of a victim system and often includes command and control callbacks, credential harvesting, and file transfer capabilities.
  • npm token: an authentication token used by CI or developers to publish or manage packages on npm; if stolen it allows attackers to publish packages under legitimate names.
  • postinstall script: an npm lifecycle script that executes during package install; attackers often abuse postinstall to run arbitrary commands during build or install time.
  • package integrity: cryptographic checks such as checksums and signed artifacts that confirm a package version has not been modified since publishing.

Common mistakes

  • Assuming npm audit will flag malicious or unauthorized publishes. npm audit reports known vulnerabilities, not malicious code or account hijacks.
  • Trusting published package names without verifying owners and publish history, especially for high-risk dependencies.
  • Not monitoring CI runners and build caches for long-lived tokens or cached artifacts. A poisoned artifact in a cache propagates faster than a single developer machine.
  • Failing to block or quarantine internal artifact stores quickly. Public unpublish requests are often slower than internal blocking and remediation.
  • Rebuilding images without rotating credentials and checking for persistence mechanisms; this can leave compromised credentials in place and allow re-infection.

Quick answer

If your environment installs axios via npm, assume risk until you validate versions and integrity. The malicious releases (reported as published from a hijacked maintainer account) contain code that attempts persistent remote access. The fast path: run the detection commands below, isolate hosts with the packages, revoke npm tokens and publish keys, remove malicious packages from build artifacts and images, and engage incident response. These actions reduce your mean time to containment from industry medians - for supply chain incidents - down to hours when executed quickly and using automated scans.

Why this matters - business risk and measured impact

  • Supply chain code runs with developer and production privileges. A poisoned JavaScript package can escalate to host-level compromise, data exfiltration, or persistent remote access.
  • Time cost if you fail to act: days of undetected compromise often becomes weeks of cleanup and containment. Example impact metrics to use in SLAs and executive reports:
    • Detection window reduced: from ~72 hours industry average to under 8 hours with automated scanning and playbook execution - risk window cut by ~90%.
    • Operational overhead: forensic triage and rebuilds can consume 10-40 incident-hours per host if not triaged quickly.
    • Revenue/availability: for high-availability web properties, each hour of forced rollback or container rebuild may cost thousands to tens of thousands of dollars in lost booking traffic or SLA penalties depending on scale.

Who this is for - and who it is not for

  • For: security teams, devops, IT leaders, MSSP/MDR operators, and CISO-level decision makers who need to act quickly and communicate breach risk.
  • Not for: purely academic audiences. This guide prioritizes actionable detection and remediation.

What happened - high level technical summary

A maintainer account on npm was hijacked and used to publish poisoned axios packages. The published artifacts include a postinstall or runtime payload that installs or executes a remote access trojan (RAT). The RAT attempts outbound connections back to attacker-controlled servers and installs persistent components.

Key attack technique elements:

  • Account compromise or stolen npm token used to publish package tarballs.
  • Malicious versions replace expected library entry points or add scripts that execute on install or on module import.
  • Downstream impact: CI jobs, build pipelines, containers, serverless functions, and runtime services that pull the tainted package become directly infected.

This is a supply chain compromise - it affects both dev and production systems that consume npm artifacts.

Immediate detection checklist

Run these checks now across your build pipeline, developer machines, CI autoscaling groups, and production hosts.

  • Find direct installs in code and lockfiles
# Find any direct dependency reference in package-lock.json and yarn.lock
grep -R "\baxios\b" package-lock.json yarn.lock || true
# Or use jq to parse package-lock.json
jq -r '..|objects|.version? // empty | select(.)' package-lock.json 2>/dev/null | grep -E "1\.|0\." || true
  • Find installed modules on hosts and in images
# List installed axios packages on a host
npm ls axios --all 2>/dev/null || true
# Search filesystem for axios-related files
find / -path "*/node_modules/axios/*" -print 2>/dev/null | head -n 50
  • Inspect suspicious published tarball before installing
# Fetch tarball without running install scripts
npm pack axios@1.14.1
# Inspect contents
tar -tzf axios-1.14.1.tgz | sed -n '1,80p'
# Check integrity reported by registry
npm view axios@1.14.1 dist.integrity
  • Check package owners and recent publish activity
# List owners and recent publish times
npm owner ls axios
npm view axios time
  • Scan images/containers for the malicious files and unexpected postinstall steps
# Search within Docker images (after exporting filesystem)
docker save myimage:latest -o myimage.tar
tar -xf myimage.tar --wildcards '*/node_modules/axios/*' || true
  • Hunt for runtime indicators of a RAT
# Linux/macOS
ps aux | egrep "(node|curl|wget|sh)" | egrep -i "(unknown-host|suspicious-domain|base64)" || true
# Check active network connections from Node processes
lsof -i -nP | egrep "node|axios" || ss -tnp | grep node

Notes: Replace ‘1.14.1’ with the specific suspect version you saw. If you find matches, treat the host as potentially compromised and follow containment steps below.

Containment and remediation checklist

If detection shows the malicious package is present, follow this prioritized list immediately.

  1. Isolate and preserve
  • Isolate affected hosts from the network or place them into a quarantined VLAN while preserving disk and memory for forensic analysis.
  • Take forensic snapshots (disk, memory) for later evidence.
  1. Revoke and rotate
  • Revoke CI/CD service tokens and npm publish tokens immediately. Rotate credentials and deploy new tokens with least privilege.
  • Rotate any cloud or host keys that were accessible to compromised CI systems. Update secrets in secret stores.
  1. Remove poisoned artifacts from artifacts stores and images
  • Remove the malicious npm versions from internal artifact caches and registries. If you proxy npm, block those versions.
  • Rebuild container images from known-good sources and redeploy after validation.
  1. Block and monitor outbound C2
  • Block known attacker domains and IPs at the network perimeter and in egress allow lists.
  • Deploy IDS/IPS rules to detect C2-like behavior and beaconing patterns.
  1. Reinstall clean dependencies
  • Freeze to the last good checksumed version and install only with integrity checks enabled.
  1. Evidence collection and logging
  • Capture package-lock.json, yarn.lock, and container image manifests from the time of suspected compromise for investigation.
  1. Notify and escalate
  • Notify legal, privacy, and executive teams per your incident notification policy. Prepare breach reporting if data exfiltration is suspected.

Timeline expectations: with an organized playbook and automation, containment within 8 hours is achievable for many orgs. Without playbooks, containment commonly takes multiple days.

Incident response playbook - step by step

This is an operator-ready sequence you can run immediately.

  • Stage 0 - Triage (first 60-120 minutes)

    • Confirm detection: capture packages and hashes, confirm malicious code presence via static inspection of the tarball.
    • Scope: enumerate hosts and CI runs that pulled the package in the last 7 days using build logs and artifact metadata.
    • Communicate: stand up incident channel, notify stakeholders.

  • Stage 1 - Containment (hour 2-6)

    • Quarantine impacted hosts and stop CI jobs that could continue to spread the package.
    • Revoke npm tokens, CI service accounts involved in publishing or installation.
    • Apply network blocking rules for identified C2 IOCs.

  • Stage 2 - Eradication (hour 6-24)

    • Rebuild images and artifacts from source at last known-good commits.
    • Patch and update runtimes to prevent re-use of the same vector.
    • Remove malicious files, and rotate credentials and secrets used by impacted systems.

  • Stage 3 - Recovery and validation (day 1-7)

    • Redeploy cleaned workloads into production lanes gradually under increased monitoring.
    • Run threat hunts for lateral movement and exfil traces in the 30 days prior to detection.
    • Retain forensics for legal/regulatory needs.

  • Stage 4 - Post-incident hardening (week 1-4)

    • Implement stricter artifact signing, enforce package integrity checks, and enable automatic alerts for new publish events on key dependencies.
    • Update SCA (software composition analysis) rules to mark certain packages as high-risk and block them by policy until validated.

Roles and responsibilities checklist

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

Suggested SLA targets for response teams

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

Recovery and rebuild - safe dependency restoration

Follow these controls when restoring dependencies:

  • Pin to a known-good checksumed version in package-lock.json or use an internal artifact repository that enforces checksums.
  • Add immutable snapshots for images and artifacts in your registry; never pull unverified remote packages into production images.
  • Enforce registry access controls and require two-factor authentication for publisher accounts.
  • Enable artifact signing and verify signatures at install time where supported.

Example commands for safe reinstall

# Install only from package-lock.json with integrity enforcement
npm ci --prefer-offline --no-audit --production

# Rebuild Docker images from lockfile-controlled sources only
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.
  • Monitor npm publish events for your transitive dependencies and alert on unexpected owner changes.

Proof elements and example scenarios

Scenario 1 - Dev workstation pull infects CI

  • Developer runs a local install that downloads a poisoned axios package and checks artifacts into a shared build cache. The CI pipeline picks up the cached artifact and builds containers that reach production. Detection point: CI pipeline logs showing package download timestamps and hash mismatches. Remediation: invalidate cache, rebuild artifacts from source commit, revoke tokens associated with CI runner.

Scenario 2 - Postinstall script executes on container build

  • A Dockerfile uses npm ci during image build. The poisoned package contains a postinstall script that creates a cron job or installs a Node-based backdoor. Evidence: malicious files under /usr/src/app/node_modules/axios/ or unexpected child processes from the build step. Remediation: rebuild with --ignore-scripts for validation, then re-run with validated packages.

Quantified expected gains

  • Using automated detection and the above playbook reduces host-level remediation time from a median of 36 hours to under 8 hours in well-prepared orgs.
  • Enforcing artifact signing and registry allowlists reduces the probability of a successful publish-based compromise by >95% because stolen tokens cannot publish to protected registries.

Objections and trade-offs

  • “We cannot freeze all packages; that will break development.” Response: Implement staged enforcement. Start by protecting production images and critical pipelines, and expand to developer flows. Use CI gating to balance velocity and security.
  • “Revoking tokens will break builds.” Response: Rotate tokens during a short maintenance window; use alternate isolated runners to maintain critical builds. This is a brief and necessary outage to prevent further spread.
  • “We saw the package but the code looks harmless; do we trust it?” Response: If any unexpected publish activity appears on a high-impact dependency, treat as suspicious until cryptographically validated and verified with publisher channels. Static code similarity and dynamic behavior can still be malicious despite harmless-looking code.

FAQ

How do I tell if my project used the malicious axios package?

Search your lockfiles and CI logs for direct or transitive dependency versions and checksums. Use npm ls axios and grep your package-lock.json and yarn.lock. If you find a match to the suspect versions or to a package with unexpected owner changes, follow the containment steps above.

Will npm audit detect this kind of malicious package?

Not reliably. npm audit checks known vulnerabilities, not malicious intent or unauthorized publish events. You need artifact integrity checks, owner/publish-time monitoring, and static/dynamic scanning to detect supply chain poisoning.

What if I already deployed containers built from the poisoned package?

Assume compromise. Isolate affected services, gather logs, and perform a hunt for outbound connections and persistence. Rebuild and redeploy from known-good sources after credential rotation and network blocking.

Should we unpublish or block the malicious versions from npm?

If you control a private registry or proxy, block at that layer first. Public unpublish requests go through npm and may be delayed. Internal mitigation is faster and under your control.

How can MSSP/MDR help with this type of incident?

MSSP and MDR providers can speed detection by applying global threat intelligence to identify C2 callbacks, scale host-level hunts across many endpoints, assist with forensics, and manage containment steps across distributed environments. They also provide evidence collection for compliance and legal reporting.

References

Authoritative, source-level reporting and advisories about this incident and related supply chain risks:

Additional reporting and technical breakdowns:

Notes: these links are source-level advisories and technical posts you can cite in incident reports and for executive briefings. Keep archived copies of registry metadata and tarballs referenced here as forensic artifacts.

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.

These options provide an immediate playbook, prioritized detection recipes, and an option to extend into MDR-led hunts and rebuild orchestration.

Next step - immediate advisory and MDR alignment

If you found evidence of axios installs matching the suspect versions, treat this as an active supply chain incident. Recommended immediate actions:

  • Run the Immediate detection checklist across CI, build artifacts, and production hosts now.
  • If you confirm presence, follow the Containment and remediation checklist and then engage forensic analysis.

If you want expert help, consider an MDR or incident response engagement for 24x7 hunts, token rotation orchestration, and rapid rebuilds. For trusted external support and next-step alignment, see:

Engaging a partner accelerates containment, provides scalable hunting capability, and helps capture legally admissible forensics.

Conclusion

A poisoned axios npm package is a high-impact supply chain event. Quick detection, immediate isolation, and a coordinated rebuild with rotated credentials will materially reduce risk and recovery time. Follow the checklists above, collect forensic evidence, and escalate to an MDR or incident response partner when scope or uncertainty exceeds internal capacity.