How to Check for Impacted axios Packages in Your SBOM June 2026

On March 30, 2026, a threat actor compromised the npm account of jasonsaayman, the primary maintainer of axios, the most popular JavaScript HTTP client library with over 100 million weekly downloads.

The malicious versions contain zero lines of malicious code inside axios itself. Instead, they inject a hidden dependency, a reminder that third-party packages require careful vetting:

plain-crypto-js@4.2.1

a package never imported anywhere in the legitimate axios source code. Its sole purpose is to execute a postinstall script that deploys a cross-platform remote access trojan (RAT) targeting macOS, Windows, and Linux.

Full coverage is available in this article from The Hacker News.

TL;DR

• On March 30, 2026, attackers hijacked the npm account of the axios maintainer and published two malicious versions: axios@1.14.1 and axios@0.30.4. Both have since been removed from the registry.
• The malicious releases injected a hidden dependency, plain-crypto-js@4.2.1, which deployed a cross-platform remote access trojan (RAT) targeting macOS, Windows, and Linux via a postinstall script.
• Arnica customers can search their SBOM for impacted packages immediately using the axios (Mar 2026) celebrity CVE filter in Arnica.
• If the malicious version ran on a system, assume full compromise: rotate all credentials, secrets, and access tokens, isolate affected hosts, and block egress to sfrclak[.]com:8000.
• To prevent this class of attack going forward, set a minimum package release age (cooldown) in your package manager config or run DepsGuard to apply these protections automatically.

Attack Overview

The attack unfolded in a precise, pre-planned sequence:

• Account compromise: The attacker obtained a long-lived classic npm access token for the jasonsaayman account and changed its registered email to an attacker-controlled ProtonMail inbox (ifstap@proton.me).

• Dependency pre-staging: The malicious package plain-crypto-js@4.2.1 was published to npm approximately 18 hours before the axios releases. This gap was intentional. By the time the poisoned axios versions appeared, plain-crypto-js was already an aged, indexed entry in the registry — not a freshly minted package that might trigger anomaly detection. The attacker also pinned axios's new package.json to reference plain-crypto-js@4.2.1 before that version was published, meaning any scanner that resolved the dependency graph at the moment of the axios publish would find the dependency field pointing to a version that did not yet exist. This is a deliberate technique to defeat tools that inspect transitive dependency trees at publish time instead of at install time.

• Poisoned releases: At 00:21 UTC on March 31, axios@1.14.1 was published. At 01:00 UTC, axios@0.30.4 followed. Both appeared in the npm registry as published by the legitimate jasonsaayman account — visually indistinguishable from legitimate releases.

• RAT deployment: The dropper in plain-crypto-js contacted a live C2 server, delivered platform-specific second-stage payloads for macOS, Windows, and Linux, then deleted itself and replaced its own package.json with a clean decoy, leaving no visible trace in node_modules after the fact.

• Additional vectors: Socket identified two additional packages distributing the same malware through vendored dependencies:

@shadanai/openclaw
@qqbrowser/openclaw-qbot@0.0.130

‍

Affected Versions

axios@1.14.1 (malicious — downgrade to 1.14.0) 

axios@0.30.4 (malicious — downgrade to 0.30.3) 

Any project using caret ranges (e.g., ^1.14.0 or ^0.30.0) would have automatically pulled in the compromised version on its next fresh install. Both versions have been removed from npm; the latest tag now points to the safe axios@1.14.0 release.

How to Check with Arnica

Arnica customers can search their SBOM for the impacted axios packages directly from the platform. We have added this zero-day CVE to Arnica's celebrity vulnerability database, allowing you to identify all affected packages across your entire codebase instantly through automated security workflows powered by Arnie AI, your code protector. Organizations in pipelineless security for compliance-driven industries to respond quickly to supply chain threats without disrupting existing development pipelines.

To find affected packages in your SBOM:

• Go to the SBOM view in Arnica.
• Use the advanced search filter and select "axios (Mar 2026)" from the celebrity CVE dropdown.
• Arnica will surface every repository and container image in your organization that references the affected versions, across all your connected SCM platforms.

Check your SBOM for affected packages using Arnica

Recommended Actions

Not finding evidence in the SBOM is a good first step, but developers may have installed the package in their local environments outside of your tracked repositories. We recommend taking the following actions across all systems:

Immediate Triage

Confirm no impacted version is present by running: npm list axios or check your lockfiles (package-lock.json, yarn.lock, bun.lockb) for references to versions 1.14.1 or 0.30.4.

Search node_modules for the malicious dependency:

find . -path '*/plain-crypto-js*'

‍

Audit CI/CD pipelines: Review build logs for the March 31, 2026 UTC window to identify which pipelines ran npm install during this period. For full protection, consider implementing CI/CD pipeline security controls that catch malicious dependencies before they reach production. ‍

Block egress to the C2 domain: sfrclak[.]com:8000 in your network/firewall rules.

If Compromise Is Confirmed

• Assume full system compromise, including stolen credentials, API keys, cloud access tokens, and crypto wallets.
• Immediately rotate all credentials, secrets, and access tokens on affected systems. ‍
• Downgrade to safe versions: axios@1.14.0 or axios@0.30.3 and purge package manager caches (npm cache clean --force).
• Isolate and reimage any confirmed affected hosts before returning them to service.
• Remove plain-crypto-js from node_modules on all systems.
• Review network egress logs for connections to sfrclak[.]com during and after the March 31 window.

Indicators of Compromise (IOCs)

• ‍Malicious npm packages: axios@1.14.1, axios@0.30.4, plain-crypto-js@4.2.1 ‍
• C2 server: sfrclak[.]com:8000 ‍
• Attacker email: ifstap@proton.me / nrwise@proton.me ‍
• Additional malicious packages:

@shadanai/openclaw (versions 2026.3.28-2, 2026.3.28-3, 2026.3.31-1, 2026.3.31-2)

@qqbrowser/openclaw-qbot@0.0.130 

Security Recommendations

• Commit and enforce lockfiles. Check in package-lock.json or pnpm-lock.yaml and use deterministic installs such as npm ci or pnpm install --frozen-lockfile so builds do not silently pick up newly published dependency versions.
• Configure npm or pnpm to delay newly published packages from being installed. Set a minimum package age, such as a 3-day cooldown, before new versions are eligible for installation.
• For example, set `minimumReleaseAge: 4320` (value in minutes) in `pnpm-workspace.yaml` for pnpm, or `min-release-age=3` (value in days) in `.npmrc` for npm. This gives the community time to detect and remove malicious releases before they reach your builds.
• For teams using pnpm, apply additional supply-chain hardening where practical. Consider settings such as:

`strictDepBuilds: true` to fail on unreviewed dependency build scripts

`blockExoticSubdeps: true` to block transitive git/ssh/https dependencies

`trustPolicy: "no-downgrade"` to reduce downgrade and takeover-related risk

‍

Arnica customers have the needed visibility into the axios package vulnerability today, with developer context that helps teams assess which vulnerabilities require immediate attention. If you're not yet an Arnica customer and want to check your exposure, get started with Arnica for free.

Harden Your Pipeline with DepsGuard

DepsGuard is a free, open-source CLI tool that hardens package manager security by activating protections that ship with npm, pnpm, yarn, bun, uv, Renovate, and Dependabot, but aren't turned on by default. It runs in 60 seconds, requires zero dependencies, and creates an automatic backup before touching any file.

What Is a Package Manager Cooldown?

A cooldown (also called minimum release age) is a package manager setting that blocks installation of any package version published less than N days ago. Most supply chain compromises are identified and removed within hours of publication. A 7-day cooldown means malicious packages are caught long before they can reach your pipeline.

The axios attack makes the value concrete. The two malicious versions were live on npm for roughly two hours before being flagged and removed. A cooldown of even a single day would have blocked every automated pipeline from ever pulling them in. No lockfile audit required. No incident to respond to. The attacker's window of opportunity closes before your builds run.

Configuring a cooldown in your

.npmrc, .yarnrc.yml, or .bunfig.toml

is one of the highest-impact, lowest-effort security controls available to engineering teams, and most pipelines don't have it turned on.

How It Works

1. Run one command
2. Reviewthe interactive diff
3. Apply a backup that is created automatically before any file is modified

DepsGuard supports npm, pnpm, yarn, bun, uv, Renovate, and Dependabot from a single CLI. It is MIT-licensed with zero runtime dependencies.

Frequently Asked Questions

Does DepsGuard work with monorepos? Yes. DepsGuard detects and configures package manager files across monorepo structures.

Will a cooldown break my CI/CD pipeline? A 7-day cooldown only affects newly published versions. Pinned dependencies and existing lockfiles are unaffected.

Is DepsGuard free? Yes. DepsGuard is free and MIT-licensed with no paid tiers.

Start hardening your software supply chain in 60 seconds at depsguard.com.

‍