Hackers slipped a trojan into the code library behind most of the internet. Your team is probably affected | Venture Beat

Overview

Attackers stole a long-lived npm access token belonging to the lead maintainer of axios, the most popular HTTP client library in Java Script, and used it to publish two poisoned versions that install a cross-platform remote access trojan. The malicious releases target mac OS, Windows, and Linux. They were live on the npm registry for roughly three hours before removal.

Axios gets more than 100 million downloads per week. Wiz reports it sits in approximately 80% of cloud and code environments, touching everything from React front-ends to CI/CD pipelines to serverless functions. Huntress detected the first infections 89 seconds after the malicious package went live and confirmed at least 135 compromised systems among its customers during the exposure window.

Details

This is the third major npm supply chain compromise in seven months. Every one exploited maintainer credentials. This time, the target had adopted every defense the security community recommended.

The attacker took over the npm account of @jasonsaayman, a lead axios maintainer, changed the account email to an anonymous Proton Mail address, and published the poisoned packages through npm’s command-line interface. That bypassed the project’s Git Hub Actions CI/CD pipeline entirely.

The attacker never touched the Axios source code. Instead, both release branches received a single new dependency: plain-crypto-js@4.2.1. No part of the codebase imports it. The package exists solely to run a postinstall script that drops a cross-platform RAT onto the developer's machine.

The staging was precise. Eighteen hours before the axios releases, the attacker published a clean version of plain-crypto-js under a separate npm account to build publishing history and dodge new-package scanner alerts. Then came the weaponized 4.2.1. Both release branches hit within 39 minutes. Three platform-specific payloads were pre-built. The malware erases itself after execution and swaps in a clean package.json to frustrate forensic inspection.

Step Security, which identified the compromise alongside Socket, called it among the most operationally sophisticated supply chain attacks ever documented against a top-10 npm package.

Axios did the right things. Legitimate 1.x releases shipped through Git Hub Actions using npm's OIDC Trusted Publisher mechanism, which cryptographically ties every publish to a verified CI/CD workflow. The project carried SLSA provenance attestations. By every modern measure, the security stack looked solid.

None of it mattered. Huntress dug into the publish workflow and found the gap. The project still passed NPM_TOKEN as an environment variable right alongside the OIDC credentials. When both are present, npm defaults to the token. The long-lived classic token was the real authentication method for every publish, regardless of how OIDC was configured. The attacker never had to defeat OIDC. They walked around it. A legacy token sat there as a parallel auth path, and npm's own hierarchy silently preferred it.

“From my experience at AWS, it’s very common for old auth mechanisms to linger,” said Merritt Baer, CSO at Enkrypt AI and former Deputy CISO at AWS, in an exclusive interview with Venture Beat. “Modern controls get deployed, but if legacy tokens or keys aren’t retired, the system quietly favors them. Just like we saw with Solar Winds, where legacy scripts bypassed newer monitoring.”

The maintainer posted on Git Hub after discovering the compromise: “I’m trying to get support to understand how this even happened. I have 2FA / MFA on practically everything I interact with.”

Endor Labs documented the forensic difference. Legitimate axios@1.14.0 showed OIDC provenance, a trusted publisher record, and a git Head linking to a specific commit. Malicious axios@1.14.1 had none. Any tool checking provenance would have flagged the gap instantly. But provenance verification is opt-in. No registry gate rejected the package.

Three npm supply chain compromises in seven months. Every one started with a stolen maintainer credential.

The Shai-Hulud worm hit in September 2025. A single phished maintainer account gave attackers a foothold that self-replicated across more than 500 packages, harvesting npm tokens, cloud credentials, and Git Hub secrets as it spread. CISA issued an advisory. Git Hub overhauled npm’s entire authentication model in response.

Then in January 2026, Koi Security’s Package Gate research dropped six zero-day vulnerabilities across npm, pnpm, vlt, and Bun that punched through the very defenses the ecosystem adopted after Shai-Hulud. Lockfile integrity and script-blocking both failed under specific conditions. Three of the four package managers patched within weeks. npm closed the report.

Now axios. A stolen long-lived token published a RAT through both release branches despite OIDC, SLSA, and every post-Shai-Hulud hardening measure in place.

npm shipped real reforms after Shai-Hulud. Creation of new classic tokens got deprecated, though pre-existing ones survived until a hard revocation deadline. FIDO 2FA became mandatory, granular access tokens were capped at seven days for publishing, and trusted publishing via OIDC gave projects a cryptographic alternative to stored credentials. Taken together, those changes hardened everything downstream of the maintainer account. What they didn’t change was the account itself. The credential remained the single point of failure.

“Credential compromise is the recurring theme across npm breaches,” Baer said. “This isn’t just a weak password problem. It’s structural. Without ephemeral credentials, enforced MFA, or isolated build and signing environments, maintainer access remains the weak link.”

What npm shipped vs. what this attack walked past

FIDO 2FA required. Granular tokens, 7-day expiry. Classic tokens deprecated

Bypassed. Legacy token coexisted alongside OIDC. npm preferred the token

No enforcement removes legacy tokens when OIDC is configured

OIDC Trusted Publishing via Git Hub Actions. SLSA attestations

Bypassed. Malicious versions had no provenance. Published via CLI

No gate rejects packages missing provenance from projects that previously had it

Partial. Socket flagged in 6 min. First infections hit at 89 seconds

Detection-to-removal gap. Scanners catch it, registry removal takes hours

Not enforced. npm runs postinstall by default. pnpm blocks by default; npm does not

postinstall remains primary malware vector in every major npm attack since 2024

Effective only if lockfile committed before compromise. Caret ranges auto-resolved

Caret ranges are npm default. Most projects auto-resolve to latest minor

SOC leaders whose organizations run Node.js should treat this as an active incident until they confirm clean systems. The three-hour exposure window fell during peak development hours across Asia-Pacific time zones, and any CI/CD pipeline that ran npm install overnight could have pulled the compromised version automatically.

“The first priority is impact assessment: which builds and downstream consumers ingested the compromised package?” Baer said. “Then containment, patching, and finally, transparent reporting to leadership. What happened, what’s exposed, and what controls will prevent a repeat. Lessons from log 4j and event-stream show speed and clarity matter as much as the fix itself.”

Check exposure. Search lockfiles and CI logs for axios@1.14.1, axios@0.30.4, or plain-crypto-js. Pin to axios@1.14.0 or axios@0.30.3.

Assume compromise if hit. Rebuild affected machines from a known-good state. Rotate every accessible credential: npm tokens, AWS keys, SSH keys, cloud credentials, CI/CD secrets, .env values.

Block the C2. Add sfrclak.com and 142.11.206.73 to DNS blocklists and firewall rules.

Check for RAT artifacts. /Library/Caches/com.apple.act.mond on mac OS. %PROGRAMDATA%\wt.exe on Windows. /tmp/ld.py on Linux. If found, preform a full rebuild.

Harden going forward. Enforce npm ci --ignore-scripts in CI/CD. Require lockfile-only installs. Reject packages missing provenance from projects that previously had it. Audit whether legacy tokens coexist with OIDC in your own publishing workflows.

Three attacks in seven months. Each different in execution, identical in root cause. npm’s security model still treats individual maintainer accounts as the ultimate trust anchor. Those accounts remain vulnerable to credential hijacking, no matter how many layers get added downstream.

“AI spots risky packages, audits legacy auth, and speeds SOC response,” Baer said. “But humans still control maintainer credentials. We mitigate risk. We don’t eliminate it.”

Mandatory provenance attestation, where manual CLI publishing is disabled entirely, would have caught this attack before it reached the registry. So would mandatory multi-party signing, where no single maintainer can push a release alone. Neither is enforced today. npm has signaled that disabling tokens by default when trusted publishing is enabled is on the roadmap. Until it ships, every project running OIDC alongside a legacy token has the same blind spot axios had.

The axios maintainer did what the community asked. A legacy token nobody realized was still active and undermined all of it.

Deep insights for enterprise AI, data, and security leaders

By submitting your email, you agree to our Terms and Privacy Notice.

Key Takeaways

Attackers stole a long-lived npm access token belonging to the lead maintainer of axios, the most popular HTTP client library in Java Script, and used it to publish two poisoned versions that install a cross-platform remote access trojan
Axios gets more than 100 million downloads per week
This is the third major npm supply chain compromise in seven months
The attacker took over the npm account of @jasonsaayman, a lead axios maintainer, changed the account email to an anonymous Proton Mail address, and published the poisoned packages through npm’s command-line interface
The attacker never touched the Axios source code