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

An access token for npm, belonging to the lead maintainer of axios, a popular JavaScript HTTP client library, was stolen by attackers. They used it to release two compromised versions featuring a cross-platform remote access trojan (RAT) targeting macOS, Windows, and Linux. These malicious versions were available on the npm registry for around three hours before they were removed.

Axios sees over 100 million downloads weekly. According to Wiz, it is present in about 80% of cloud and code environments, impacting everything from React front-ends to CI/CD pipelines and serverless functions. Huntress identified the first infections just 89 seconds after the malicious package was released, confirming at least 135 compromised systems during this period.

This marks the third significant npm supply chain attack in seven months, each involving stolen maintainer credentials. This incident occurred despite the maintainer following recommended security practices.

One credential, two branches, 39 minutes

The attacker hijacked the npm account of @jasonsaayman, a lead axios maintainer, altering the account email to an anonymous ProtonMail address and releasing the compromised packages via npm’s command-line interface. This circumvented the project’s GitHub Actions CI/CD pipeline.

The attackers did not modify the Axios source code. Instead, they added a new dependency, plain-crypto-js@4.2.1, to both release branches. This package, not imported anywhere in the codebase, is designed solely to execute a postinstall script that deploys a cross-platform RAT onto the developer’s machine.

The operation was meticulously planned. Eighteen hours before releasing the compromised axios versions, the attacker published a clean version of plain-crypto-js from a different npm account to establish publishing history and avoid triggering new-package scanner alerts. The weaponized version 4.2.1 followed, affecting both release branches within 39 minutes. Three platform-specific payloads were pre-prepared. The malware self-deletes post-execution and replaces itself with a clean package.json to hinder forensic analysis.

StepSecurity, in collaboration with Socket, described this as one of the most sophisticated supply chain attacks documented against a top-10 npm package.

The defense that existed on paper

Axios implemented recommended security measures. Legitimate 1.x releases were deployed via GitHub Actions using npm‘s OIDC Trusted Publisher mechanism, ensuring each publish was cryptographically linked to a verified CI/CD workflow. The project also had SLSA provenance attestations, making its security measures seem robust on paper.

However, these defenses proved ineffective. Huntress identified a flaw in the publish workflow. The project continued to use NPM_TOKEN as an environment variable alongside OIDC credentials. When both are present, npm defaults to the token, making the long-lived classic token the true authentication method for all publishes. The attacker bypassed OIDC entirely, exploiting the legacy token that remained as an alternate authentication path, which npm‘s hierarchy silently favored.

“In my experience, legacy authentication methods often persist,” said Merritt Baer, CSO at Enkrypt AI, in an interview with VentureBeat. “While modern controls are implemented, if old tokens or keys are not retired, the system continues to favor them, similar to what happened with SolarWinds, where outdated scripts bypassed newer monitoring systems.”

Following the breach, the maintainer stated on GitHub: “I’m trying to get support to understand how this even happened. I have 2FA/MFA on almost everything I use.”

Endor Labs highlighted the forensic differences. Legitimate axios@1.14.0 included OIDC provenance, a trusted publisher record, and a gitHead linking to a specific commit, while the malicious axios@1.14.1 lacked these elements. Any tool checking provenance would have immediately flagged this discrepancy, but provenance verification is not mandatory. Consequently, no registry gate blocked the package.

Three attacks, seven months, same root cause

Over the past seven months, there have been three npm supply chain breaches, each beginning with the theft of a maintainer credential.

The Shai-Hulud worm occurred in September 2025, where a single phished maintainer account allowed attackers to infiltrate and replicate themselves across over 500 packages, collecting npm tokens, cloud credentials, and GitHub secrets during the process. CISA issued an advisory, prompting GitHub to overhaul npm's authentication model.

In January 2026, Koi Security’s PackageGate research unveiled six zero-day vulnerabilities across npm, pnpm, vlt, and Bun, penetrating the defenses established post-Shai-Hulud. Lockfile integrity and script-blocking faltered under certain conditions. Three out of four package managers patched the vulnerabilities within weeks, while npm closed the report.

Now, axios has fallen victim. A stolen long-lived token permitted the publication of a RAT through both release branches, despite implementing OIDC, SLSA, and all post-Shai-Hulud hardening measures.

Following Shai-Hulud, npm enacted significant reforms. The creation of new classic tokens was deprecated, though existing ones persisted until a hard revocation deadline. FIDO 2FA became mandatory, granular access tokens were limited to seven days for publishing, and trusted publishing via OIDC provided a cryptographic alternative to stored credentials. Collectively, these changes fortified everything downstream of the maintainer account. However, the account itself remained a vulnerability.

“Credential compromise is the recurring theme across npm breaches,” Baer noted. “This isn’t just about weak passwords. It’s a structural issue. 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

What to do now at your enterprise

SOC leaders whose organizations utilize Node.js should treat this as an active incident until systems are confirmed clean. The three-hour exposure window coincided with peak development hours in Asia-Pacific, and any CI/CD pipeline that executed npm install overnight might have automatically incorporated the compromised version.

“The first priority is impact assessment: identifying which builds and downstream consumers ingested the compromised package,” Baer suggested. “Following this, containment, patching, and transparent reporting to leadership are essential. Understanding what occurred, what’s at risk, and what measures will prevent recurrence is vital. Experiences from log4j and event-stream demonstrate that speed and clarity are as important 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 macOS. %PROGRAMDATA%\wt.exe on Windows. /tmp/ld.py on Linux. If found, perform 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.

The credential gap nobody closed

Three attacks in seven months, all different in method but sharing a common root cause. npm’s security framework continues to rely on individual maintainer accounts as the primary trust point, leaving them susceptible to credential hijacking regardless of downstream security layers.

“AI detects risky packages, reviews legacy authentication, and accelerates SOC response,” Baer said. “However, humans still manage maintainer credentials. We can reduce risk, but not eliminate it.”

Mandatory provenance attestation, which entirely disables manual CLI publishing, could have intercepted this attack before registry entry. Similarly, mandatory multi-party signing, requiring more than one maintainer for a release, would have helped. Neither is currently enforced. npm plans to disable tokens by default when trusted publishing is active. Until that feature is implemented, any project using OIDC alongside a legacy token faces the same vulnerability as axios.

The axios maintainer complied with community standards, yet an overlooked legacy token compromised the entire effort.