Hackers introduced a Trojan into the code library behind most of the Internet. Your computer is probably affected

The attackers stole a long-lived npm access token belonging to the main maintainer of axiosthe most popular HTTP client library in JavaScript, and used it to publish two poisoned versions that install a cross-platform remote access Trojan. The malicious launches target macOS, Windows and Linux. They were active in the npm registry for about three hours before being removed.

Axios gets over 100 million downloads per week. wizard reports It is found in about 80% of code and cloud environments, covering everything from React interfaces to CI/CD pipelines and serverless functions. Hunter detected the first infections 89 seconds after the malicious package was activated and confirmed at least 135 compromised systems among its customers during the exposure window.

This is the third big npm supply chain commitment in seven months. They all exploited the maintainer’s credentials. This time, the target had adopted all the defenses recommended by the security community.

One credential, two branches, 39 minutes

The attacker seized the npm account @jasonsaayman, a core axios maintainer, changed the account email to an anonymous ProtonMail address and posted the poisoned packets via npmThe command line interface. That completely bypassed the project’s GitHub Actions CI/CD process.

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 cares for it. The package exists solely to run a post-installation script that places a cross-platform RAT on the developer’s machine.

The staging was precise. Eighteen hours before the release of axios, the attacker published a clean version of plain-crypto-js under a separate npm account to create a posting history and avoid scanner alerts for new packages. Then came the assembled 4.2.1. Both release branches arrived within 39 minutes. Three platform-specific payloads were pre-designed. The malware is deleted after execution and swapped into a clean.json package to thwart forensic inspection.

StepSecuritythat identified the commitment along with Plugrated it one of the most operationally sophisticated supply chain attacks ever documented in a top 10 npm package.

The defense that existed on paper

Axios did the right thing. Legitimate 1.x versions pushed via GitHub Actions using npmThe OIDC Trusted Publisher mechanism, which cryptographically links each publication to a verified CI/CD workflow. The project had SLSA certifications of origin. By all modern standards, the security stack seemed solid.

None of that mattered. Huntress dug deeper into publishing workflow and I found the hole. The project still passed NPM_TOKEN as an environment variable next to the OIDC credentials. When both are present, npm The default value is token. The classic long-lived token was the actual authentication method for every post, regardless of how OIDC was configured. The attacker never had to defeat the OIDC. They surrounded him. A legacy token was there as a parallel authentication path, and npmThe hierarchy itself preferred it in silence.

“In my experience at AWS, it’s very common for old authentication mechanisms to persist,” said Merritt Baer, ​​CSO at Enkrypt AI and former AWS Deputy CISO, in an exclusive interview with VentureBeat. “Modern controls are implemented, but if legacy tokens or keys are not retired, the system silently favors them. Just as we saw with SolarWinds, where legacy scripts bypassed newer monitoring.”

the maintainer published on GitHub after discovering the compromise: “I’m trying to get support to understand how this happened. I have 2FA/MFA on pretty much everything I interact with.”

Documented Endor Laboratories The forensic difference. Legitimate axios@1.14.0 showed OIDC provenance, a trusted publisher record, and a gitHead link to a specific commit. Malicious axios@1.14.1 I didn’t have any. Any tool that verified provenance would have pointed out the gap instantly. But verification of provenance is voluntary. No registration gate rejected the package.

Three attacks, seven months, same root cause

Three npm supply chain commitments in seven months. They all started with a stolen maintainer credential.

He Shai-Hulud Worm hit in September 2025. A single spoofed maintenance account gave attackers a foothold that self-replicated throughout more than 500 packagesharvest npm tokens, cloud credentials, and GitHub secrets as it spreads. CISA issued a notice. GitHub revised npm’s complete authentication model in response.

Then in January 2026, Koi Security PackageGate investigation eliminated six zero-day vulnerabilities in npm, pnpm, vltand Bun that went through the same defenses that the ecosystem adopted after Shai-Hulud. Lock file integrity and script lock failed under specific conditions. Three of the four package managers patched within weeks. npm closed the report.

Now axios. A long-lived stolen token posted a RAT across both release branches despite OIDC, SLSA, and all post-Shai-Hulud hardening measures implemented.

npm sent royal reforms after Shai-Hulud. The creation of new classic tokens became obsolete, although pre-existing ones survived until a strict revocation deadline. FIDO 2FA became mandatory, granular access tokens were limited to seven days for publication, and trusted publishing through OIDC gave projects a cryptographic alternative to stored credentials. Together, those changes strengthened everything after the maintainer account. What they didn’t change was the account itself. The credential remained the only point of failure.

“Credential compromise is the recurring theme throughout npm violations,” Baer said. “This is not just a weak password problem. It is structural. Without ephemeral credentials, mandatory MFA, or sandboxed build and sign environments, maintainer access remains the weak link.”

What npm sent vs. what happened this attack

What SOC Leaders Need	npm sent defense	vs axios attack	the gap
Block the publication of stolen tokens	FIDO 2FA is required. Granular tokens, expiration of 7 days. Obsolete Classic Tokens	Overlooked. The legacy token coexisted with OIDC. npm preferred the token	No application removes legacy tokens when OIDC is configured
Verify package origin	Trusted OIDC publishing via GitHub Actions. SLSA Certifications	Overlooked. The malicious versions had no provenance. Published via CLI	No door rejects packages that lack provenance from projects that previously had it
Detect malware before installing it	Automated Socket, Snyk and Aikido Scanning	Partial. Plug marked in 6 min. First infections reach 89 seconds	Gap between detection and elimination. Scanners detect it, deleting the registry takes hours
Block execution after installation	–ignore-recommended scripts in CI/CD	Not applied. npm runs postinstall by default. pnpm default blocks; npm No	postinstall remains the main malware vector in all major npm attack from 2024
Lock dependency versions	Lockfile App via npm ci	Effective only if the lock file was committed before the commit. Automatically resolved collation ranges	The collation ranges are npm default. Most projects are automatically resolved to the last minor

What to do now in your company

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

“The first priority is impact assessment: who are the consumers who built and subsequently 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 it from happening again. Lessons from log4j and event-stream show that speed and clarity are just as important as the solution itself.”

• Check the exposure. Search crash files and CI logs for axios@1.14.1, axios@0.30.4either plain-crypto-js. Pin to axios@1.14.0 either axios@0.30.3.

• Make a commitment if you get hit. Rebuild affected machines from a known good state. Rotate all accessible credentials: npm tokens, AWS keys, SSH keys, cloud credentials, CI/CD secrets, .env values.

• Block 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 macOS. %PROGRAMDATA%\wt.exe on Windows. /tmp/ld.py on Linux. If found, perform a complete rebuild.

• Harden in the future. Enforce npm ci --ignore-scripts in CI/CD. Requires lock file only installations. Reject packages that lack provenance from projects that previously had it. Audit whether legacy tokens coexist with OIDC in your own publishing workflows.

The credentials gap that no one closed

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

“AI detects risky packets, audits legacy authentication, and accelerates the SOC response,” Baer said. “But humans still control maintenance credentials. We mitigate the risk. We don’t eliminate it.”

Mandatory provenance certification, where manual CLI publishing is completely disabled, would have detected this attack before it reached the registry. So would mandatory multi-party signing, where no maintainer can push a release alone. Neither of them applies today. npm has noted 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 spots it had.

The axios maintainer did what the community asked of him. A legacy token that no one realized was still active and undermined everything.

Source link