Eighteen hours of staging, two malicious versions, zero exploited npm vulnerabilities. When axios lead maintainer jasonsaayman’s credentials were stolen on March 30, 2026, the attacker used them to publish axios@1.14.1 and axios@0.30.4, each carrying a phantom dependency that silently deployed a cross-platform RAT. Vercel blocked the command-and-control endpoint at its build-infrastructure boundary before issuing its advisory, intercepting the attack at the deploy layer because the registry layer did not.
The attack timeline
The attacker staged the compromise over roughly 18 hours. At 05:57 UTC on March 30, a clean package called plain-crypto-js@4.2.0 was published to npm, building registry history as a decoy. The malicious plain-crypto-js@4.2.1 followed at 23:59 UTC. Then axios@1.14.1 appeared at 00:21 UTC on March 31, and axios@0.30.4 at 01:00 UTC, according to Trend Micro’s analysis.
Both malicious axios versions added plain-crypto-js@4.2.1 as a dependency but never imported it in code. The package’s postinstall hook was the entire attack surface: npm install ran it, and the RAT landed. Automated npm scanners flagged the malicious dependency within six minutes. All compromised versions were removed from the registry by approximately 03:30 UTC.
The credentials belonged to axios lead maintainer jasonsaayman. The attacker changed the associated email to ifstap@proton.me. No corresponding commit, tag, or release exists in the axios GitHub repository for either version.
How the RAT worked
The plain-crypto-js setup.js dropper deployed platform-specific payloads targeting macOS, Windows, and Linux, as documented in Microsoft’s mitigation writeup. All three connected to the same C2 endpoint at sfrclak.com.
Microsoft Threat Intelligence attributed the attack to Sapphire Sleet, a North Korean state actor.
The OIDC provenance gap
Every legitimate axios release carries OIDC trusted publisher metadata, reflecting automated publishing through GitHub Actions. The two malicious versions bypassed these safeguards, published manually using a stolen npm token under the compromised jasonsaayman account with the attacker-controlled proton.me email, according to Trend Micro.
The npm registry accepted both versions without flagging the absence of OIDC binding. The provenance metadata was designed to make credential-theft attacks visible. It works only if something checks it before the package reaches a build pipeline.
Vercel’s deploy-time interception
Vercel’s changelog bulletin confirmed the platform had already blocked outgoing access from its build infrastructure to the C2 hostname sfrclak.com before publishing its advisory. The community forum remediation guide directed users to pin to axios@1.14.0, search lockfiles for plain-crypto-js, redeploy, and rotate build-environment secrets.
The operative detail: Vercel intercepted the attack at the deploy layer, not the install layer. When npm install inside a Vercel build pulled a tainted axios version, the postinstall hook’s attempt to phone home was blocked at the network boundary. The package still ran, but the payload had nowhere to connect.
The registry shipped the malicious code. Vercel made sure it couldn’t call home from Vercel’s infrastructure.
The Context.ai breach, two weeks later
On April 19, 2026, Vercel disclosed a separate security breach originating from a compromised third-party AI tool called Context.ai. An employee’s Google Workspace account was accessed, exposing “some Vercel environments and environment variables not marked as sensitive,” according to Vercel’s Wikipedia entry. A threat actor affiliated with ShinyHunters claimed responsibility and offered stolen data for $2 million on BreachForums.
This is a different incident with a different attacker and a different vector. But the timing complicates the narrative. The axios response showed Vercel blocking supply chain attacks at the infrastructure boundary. The Context.ai breach showed that Vercel’s own attack surface includes the same third-party dependency problem it mitigated for its customers.
Hosting providers as supply chain gatekeepers
Vercel’s deploy-time blocking treats the npm registry as an untrusted input by default. The registry publishes a package; the hosting provider filters before it executes in a build environment. This is a network-level denylist applied at the hosting layer, not registry-level trust enforcement.
The approach caught this attack because the payload phoned home to a known C2 endpoint. A supply chain attack that exfiltrates data through the build artifact itself, or operates entirely within the build without network callbacks, would pass through egress filtering unimpeded. Vercel’s block neutralized the C2 channel, not the execution of untrusted code.
CISA’s formal advisory on April 20, 2026, referencing the axios post-mortem and Microsoft’s mitigation blog, elevates the incident to federal-agency awareness. The advisory validates severity but does not address the structural gap: the registry accepted and distributed packages lacking provenance metadata present in every prior legitimate release.
What ops teams should check now
Pin axios versions. Lock to axios@1.14.0 or earlier confirmed-clean releases. Both axios@1.14.1 and axios@0.30.4 are compromised.
Search lockfiles for plain-crypto-js. Any occurrence indicates a pulled tainted version.
grep -r "plain-crypto-js" package-lock.json yarn.lock pnpm-lock.yamlcatches it.Verify OIDC publisher metadata. Legitimate axios releases carry OIDC trusted publisher metadata from GitHub Actions. Any version where this provenance is absent or shows manual publishing warrants investigation.
Rotate build-environment secrets. If a tainted version ran in any CI or deploy pipeline, assume secrets in the build environment were exposed. Rotate API keys, tokens, and deploy credentials.
Audit transitive dependencies. Axios is a transitive dependency in tens of thousands of JS projects. Your lockfile likely pulls it indirectly through frameworks, libraries, or tools that don’t advertise axios as a direct dependency.
Frequently Asked Questions
Would deployments on other platforms have had equivalent protection?
Vercel’s C2 block applied only to its own build infrastructure. Projects deploying to AWS, Cloudflare Workers, or self-hosted CI had no network-level equivalent and would have executed the RAT unless they independently blocked sfrclak.com (resolving to 142.11.206.73 on a Hostwinds VPS) before running npm install.
What makes Sapphire Sleet distinct from typical npm supply chain actors?
Sapphire Sleet (also tracked as BlueNoroff, CryptoCore, UNC1069, and STARDUST CHOLLIMA) has been active since at least March 2020 and primarily targets cryptocurrency and finance-sector organizations through spear-phishing. The axios attack is a departure from that playbook: a broad-spectrum hijacking of a package with tens of millions of weekly downloads rather than targeted social engineering against specific individuals.
What did the RAT actually drop on each OS?
On macOS, a native binary landed at /Library/Caches/com.apple.act.mond. On Windows, a renamed PowerShell binary at %PROGRAMDATA%\wt.exe with a registry persistence key. On Linux, a Python payload at /tmp/ld.py. The dropper selected the OS-specific payload via POST body parameters (product0, product1, product2) sent to the C2 endpoint.
Why did one hostname neutralize the entire attack?
Every variant across all three operating systems phoned home to the same domain on a single Hostwinds VPS. Blocking one hostname killed the C2 channel globally. An operator using domain-generation algorithms, CDN-fronted command channels, or exfiltration through the build artifact itself (no network callback needed) would pass through egress filtering entirely.