Axios Supply Chain Attack 2026: Are Your Apps Affected?
Security Advisory — Axios npm Package Compromised
On March 31, 2026, two malicious versions of the popular Axios HTTP library were published to npm: 1.14.1 and 0.30.4. Microsoft Threat Intelligence has attributed the attack to Sapphire Sleet, a North Korean state actor. Both versions install a hidden RAT (Remote Access Trojan) targeting Windows, macOS, and Linux.
Quick Checklist: Are You Affected?
Run through these checks in order. If any of them hit, follow the remediation steps below immediately.
Check package.json
Look for Axios in your dependencies. Any version range that resolves to 1.14.1 or 0.30.4 is affected.
# Dangerous — these ranges may have auto-resolved to the bad version "axios": "^1.14.0" ← resolves to 1.14.1 "axios": "^0.30.0" ← resolves to 0.30.4 "axios": "1.14.1" ← directly pinned to bad version
Check your lock file
The lock file (package-lock.json or yarn.lock) records the exact resolved version. Search for both package names:
# In package-lock.json or yarn.lock, search for: "axios@1.14.1" "axios@0.30.4" "plain-crypto-js" ← the injected malicious dependency
The presence of plain-crypto-js in any lock file is a red flag, regardless of Axios version.
Check node_modules
If node_modules is present locally or in a container image:
ls node_modules | grep plain-crypto-js cat node_modules/axios/package.json | grep '"version"'
Check CI/CD pipeline logs
Search your build logs for any npm install or npm ci executions between March 31 and April 2, 2026 that resolved Axios. If your pipeline runs on shared build agents, those machines may be compromised even if your application code is safe.
Check for network connections and persistence artifacts
Look for outbound traffic to the known C2 infrastructure and check for files dropped by the RAT:
| Platform | Check for |
|---|---|
| All | Outbound connections to sfrclak.com:8000 or IP 142.11.206.73 |
| macOS | /Library/Caches/com.apple.act.mond |
| Windows | %PROGRAMDATA%\wt.exe, registry key HKCU\...\Run\MicrosoftUpdate |
| Linux | /tmp/ld.py |
Run npm audit
npm audit # or for a clean install first: npm ci && npm audit
What Happened — The Attack in Brief
The attackers published a fake package, plain-crypto-js@4.2.1, and injected it as a dependency into axios@1.14.1 and axios@0.30.4. Axios's own source code was not changed — the malicious payload was hidden inside the dependency and executed automatically via npm's postinstall lifecycle hook. No user interaction was required.
Any project that ran npm install or npm update with a version range like ^1.14.0 or ^0.30.0 automatically pulled the malicious version. This is a textbook supply chain attack: the application itself looks fine; the compromise happens at the dependency installation layer.
After execution, the loader deleted its own traces and replaced the manifest with a clean-looking stub, making post-incident forensics harder. The malicious postinstall hook also included logic to attempt re-infection on subsequent updates.
Why You Need a Software Bill of Materials (SBOM)
A Software Bill of Materials (SBOM) is a complete, machine-readable inventory of every component in your software — every library, package, and transitive dependency, down to the exact version. Think of it as the ingredient list on a food product, but for your application.
Manufacturers have used Bills of Materials for decades to track components and react quickly to defects. The same principle applies to software: when a vulnerability like this Axios attack is published, an SBOM lets you answer the question "are we affected?" in minutes rather than hours or days.
Without an SBOM
- ✗ Manual search across all repositories
- ✗ Hours to determine exposure
- ✗ Easy to miss transitive dependencies
- ✗ No audit trail for compliance
With an SBOM
- ✓ Query all projects in minutes
- ✓ Includes transitive dependencies automatically
- ✓ Machine-readable — can be integrated into tooling
- ✓ Satisfies NIS2, ISO 27001, and customer audit requirements
Generating an SBOM for Node.js Projects
npm has built-in SBOM support. Generate a CycloneDX-format SBOM with:
# Generate SBOM in CycloneDX JSON format (npm >= 7) npm sbom --sbom-format cyclonedx --sbom-type application > sbom.json # Or using a dedicated tool (more features, supports monorepos) npx @cyclonedx/cyclonedx-npm --output-file sbom.json
The two main SBOM standards are CycloneDX (OWASP) and SPDX (Linux Foundation). Both are widely supported by security tooling. CycloneDX is generally preferred for vulnerability management use cases.
Actionable Steps — What to Do if You're Affected
Immediate (within the hour)
- Pin Axios to a safe version in
package.json:"axios": "1.14.0"(exact, no caret) - Run
npm cache clean --forceto flush any cached malicious packages - Run
npm cito reinstall from the updated lock file - Rotate all secrets and credentials that were present on affected systems — API keys, tokens, database passwords, SSH keys
- Block outbound traffic to
sfrclak.comand142.11.206.73at firewall level
Short-term (within the day)
- Audit all systems where
npm installran between March 31 and April 2, 2026 — including CI/CD build agents and developer machines - Remove persistence artifacts (see checklist above)
- For Windows: remove registry key
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdateand delete%PROGRAMDATA%\wt.exe - Review and re-issue any certificates or signing keys accessible from affected build systems
- Add an
overridesblock inpackage.jsonto force Axios version even in transitive dependencies
// package.json — force safe version even for transitive deps
{
"overrides": {
"axios": "1.14.0"
}
}Structural improvements (this week)
- Switch all production dependencies from version ranges (
^x.y.z) to exact pins - Use
npm ciinstead ofnpm installin CI pipelines — it respects the lock file exactly and fails if it's out of sync - Add
npm audit --audit-level=moderateas a failing step in your CI pipeline - Consider
npm ci --ignore-scriptsin CI to block postinstall hooks — this would have prevented this attack entirely - Generate and store an SBOM as part of your build artifacts going forward
How DeViLink Handles Supply Chain Security
Supply chain attacks are not a new phenomenon, but they are becoming more sophisticated. Here is how we approach dependency security across all client projects — and what we recommend as baseline practice for any development team.
SBOM as a Standard Build Artifact
Every project we deliver ships with a CycloneDX SBOM generated at build time and stored alongside the release artifact. This is not a one-time exercise — it is regenerated on every build so it always reflects the actual installed dependency tree, including transitive dependencies. When an advisory is published, we can cross-reference all active project SBOMs in minutes to determine which clients are affected and by how much.
Lock File Discipline
Lock files (package-lock.json or yarn.lock) are always committed to version control and treated as first-class artifacts. CI pipelines use npm ci exclusively — not npm install — which ensures the installed dependency tree exactly matches what was reviewed and approved. A PR that touches the lock file gets the same scrutiny as any other code change.
This would not have prevented the Axios attack on its own (the lock file would have been updated automatically by a developer running npm install), but lock file discipline means that the update would have been visible as a diff in a pull request — a human checkpoint before the malicious version reached production.
Exact Version Pinning in Production
We do not use caret (^) or tilde (~) in production dependency specifications. Every production dependency is pinned to an exact version. Upgrades are intentional, go through a dedicated PR, and are tested before deployment. This eliminates the "surprise update" vector that made this Axios attack so effective against projects using ^1.14.0.
CI/CD Security Gate
Every CI pipeline includes a security gate that runs before deployment:
# In every CI pipeline (GitHub Actions, GitLab CI, etc.) - npm ci --ignore-scripts # Blocks malicious postinstall hooks - npm audit --audit-level=high # Fails build on high/critical CVEs - npm sbom --sbom-format cyclonedx > sbom.json # Generate SBOM artifact
The --ignore-scripts flag is the single most effective control against the attack vector used here. The malicious payload in plain-crypto-js@4.2.1 ran exclusively via the postinstall hook. Disabling scripts blocks it entirely.
Advisory Monitoring and Proactive Client Communication
We subscribe to security advisories from the GitHub Advisory Database, OSV (Open Source Vulnerabilities), and ecosystem-specific feeds. When an advisory is published that affects commonly used packages, we run an SBOM cross-reference across active client projects immediately. Affected clients receive a written notification with a severity assessment and a concrete remediation plan — before they have to ask.
Dependency Review in Pull Requests
Any PR that modifies package.json or the lock file is flagged for explicit dependency review. We use GitHub's built-in Dependency Review Action to surface newly introduced packages, version changes, and any known vulnerabilities in the diff — before the branch is merged. For projects with elevated security requirements, we additionally run manual review of new transitive dependencies before approval.
Private Registry for High-Security Workloads
For clients in regulated industries or with elevated security requirements, we recommend and configure a private npm registry (Verdaccio or GitHub Packages) as a proxy in front of the public registry. This allows scoping of allowed packages, caching of approved versions, and blocking of packages that introduce postinstall scripts or that fail an internal review. It adds an extra layer between the public npm ecosystem and your production build pipeline.
The Honest Assessment
No security practice eliminates supply chain risk entirely. The Axios attack was sophisticated: the malicious package looked legitimate, had publishing history, and left no trace in the application's runtime code. Even a team with strong security hygiene could have been exposed during the 18-hour window before the packages were taken down.
What good practice does is reduce your blast radius and accelerate your response time. An SBOM turns a multi-day investigation into a 10-minute query. Exact version pinning means you were never exposed unless you intentionally upgraded. --ignore-scripts in CI would have blocked the payload entirely. Layered controls work even when individual ones fail.
Not Sure If Your Projects Are Affected?
We can run a rapid SBOM-based dependency audit across your codebase and give you a clear answer within one business day. We will also review your CI/CD pipeline for supply chain security gaps and provide a prioritized remediation plan.
