Axios bajo fuego: así se gestó el ataque a la cadena de suministro en npm

Home » Python » Axios bajo fuego: así se gestó el ataque a la cadena de suministro en npm

For a few tense hours, one of the most widely used JavaScript libraries on the planet, Axios, became an unexpected delivery vehicle for malware. A targeted supply chain attack on the npm ecosystem turned a routine dependency update into a potential backdoor for attackers on hundreds of thousands of developer machines and build systems.

Investigators from several security firms and Google’s Threat Intelligence Group pieced together how a malicious actor slipped a remote access trojan (RAT) into specific Axios releases on npm, similar to the npm supply‑chain worm.

What Axios is and why the compromise matters so much

At its core, Axios is a promise-based HTTP client for Node.js and browsers. It sits behind the scenes in countless projects, handling everyday tasks like “fetch my messages from the server” or “submit this form to the API” without developers having to write low‑level networking code by hand.

Because it runs both in the browser and on Node.js servers, Axios has become a foundational dependency in modern JavaScript stacks. You may never have installed it explicitly, yet you still rely on it indirectly when you:

• Use web applications built with frameworks such as React, Vue or Angular that wrap their API calls with Axios.
• Run desktop or mobile apps built on technologies like Electron, React Native and similar web‑based runtimes.
• Interact with smaller SaaS tools, admin dashboards or self‑hosted services whose developers chose Axios for HTTP requests.

In that sense, Axios is a bit like the plumbing in your house: you rarely think about it, but it carries the data “water” between your app and the outside world. You only really notice it when there is a leak—exactly what this attack created, but at software ecosystem scale.

How the Axios npm attack unfolded

The incident centers on two npm releases: axios@1.14.1 and axios@0.30.4. Using compromised credentials for one of the project’s main maintainers, attackers managed to publish malicious builds directly to npm while leaving the public GitHub source code untouched, a pattern also described in the Shai‑Hulud analysis.

Instead of visibly altering Axios’ code, the attacker added a new, seemingly unrelated dependency: plain-crypto-js@4.2.1. This package was crafted specifically for the operation and was not imported anywhere in Axios’ source files, a red flag for anyone scrutinizing the diff—but easy to miss in automated workflows that simply trust the registry.

Together, the two tainted axios versions had an enormous potential footprint, reaching up to around 100 million weekly downloads on npm. Axios is estimated to be present in close to 80% of cloud environments and CI/CD pipelines, so even a brief exposure window represented a serious systemic risk.

Crucially, the affected versions never showed up in the official GitHub tags for the Axios project. That detail strongly suggests that normal release processes were bypassed: the attacker leveraged a stolen npm token to push packages straight to the registry, out of band from the public source history.

The mechanics of the malicious dependency and the RAT

The heart of the compromise lies in what happened at install time. Any workflow that ran npm install and pulled in axios@1.14.1, axios@0.30.4 or plain-crypto-js@4.2.1 with scripts enabled triggered a hidden postinstall routine.

Inside the malicious dependency, a postinstall script (node setup.js) executed automatically. That script downloaded an obfuscated dropper, which then fetched a platform‑specific RAT payload tailored to macOS, Windows or Linux. The RAT granted the attacker interactive remote access to the compromised machine.

Once active, this remote access trojan could enumerate the system, harvest secrets and run arbitrary commands. Think cloud API keys, CI deployment tokens, npm auth tokens, SSH keys, repository access tokens and other sensitive environment variables commonly injected into build agents or developer laptops.

From there, attackers could pivot: checking out source code, tampering with future releases, adding more backdoors or moving laterally into production infrastructure. For developers working on crypto‑related projects—wallets, exchanges, DeFi frontends—this kind of access could translate directly into cryptocurrency theft or broader financial fraud.

Stealth tactics: why the compromise was hard to spot

The malware authors went to some lengths to keep their footprint as small and ephemeral as possible. According to researchers, the dropper cleaned up its tracks immediately after execution.

That means that if you examined node_modules/plain-crypto-js/package.json after infection, you would see a completely innocuous manifest: no postinstall script, no setup.js, no obvious indicators of foul play. Standard tools like npm audit or a cursory manual directory check would not reveal what had already happened.

In practice, this behavior left investigators relying on external indicators of compromise (IOCs), network telemetry and host artefacts rather than simple static scans of the npm package content. By the time the attack was public, the malicious versions had already been pulled from npm, further complicating reconstruction of the exact execution flow.

Key indicators of compromise for the Axios incident

Even though the malware tried to cover its tracks, security teams have shared concrete IOCs that can help determine whether an environment was impacted. Among the most important are the following:

On the network side, look for communication with:

• Domain: sfrclakcom
• IP address: 142.11.206.73

Both indicators have been blocked by mainstream security vendors, but they remain useful markers in historical logs and SIEM searches.

On the filesystem, investigators highlighted artefacts associated with the RAT:

• macOS: /Library/Caches/com.apple.act.mond
• Linux: /tmp/ld.py
• Windows: files under %PROGRAMDATA%\wt and temporary scripts such as %TEMP%\6202033.vbs or .ps1 that may exist only briefly during execution

In terms of npm packages, the compromised builds and their known checksums are:

• axios@1.14.1, SHA-256: 2553649f2322049666871cea80a5d0d6adc700ca
• axios@0.30.4, SHA-256: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
• plain-crypto-js@4.2.1, SHA-256: 07d889e2dadce6f3910dcbc253317d28ca61c766

Security firms such as Huntress observed at least 135 systems contacting the attacker’s command-and-control server during the relatively short exposure window, and researchers from Google warned that “hundreds of thousands” of secrets may ultimately have been siphoned off as a result.

Who was behind the attack? Attribution and the North Korea link

Google’s Threat Intelligence Group has publicly linked the Axios compromise to a suspected North Korean threat actor tracked as UNC1069. John Hultquist, chief analyst at Google’s threat unit, noted that North Korean operators have a long track record of supply chain attacks aimed at stealing cryptocurrency and other assets.

According to Google and other security vendors, the Axios incident appears to be part of a broader campaign by North Korean groups, including outfits like Lazarus, that focus on extortion, financial theft and data exfiltration targeting sectors such as crypto, fintech and cloud infrastructure.

While the full impact is still unclear, the combination of a hugely popular package, access to developer environments and the nature of the stolen data leads analysts to expect follow‑on attacks in the form of further supply chain compromises, ransomware and direct crypto theft.

How the maintainer account and npm workflow were abused

One of the most unsettling aspects for the open‑source community is how the attackers managed to publish malicious Axios versions without touching the public codebase. The key was a compromised maintainer account on npm, believed to belong to a primary Axios maintainer known as jasonsaayman.

Attackers reportedly changed the email address associated with that npm account to an address under their control. With that step, they could lock out the legitimate maintainer and push new package versions as if they were genuine updates, all while the official GitHub repository remained clean.

The operation also shed light on a structural problem in npm: support for legacy authentication tokens, and the need for supply‑chain management tools and stricter token policies.

In this case, security researchers pointed out that npm still defaulted to the legacy token for publishing, and no control automatically revoked that token once more modern publishing methods were configured. That coexistence created a vulnerable side door that UNC1069 could exploit.

Exposure window and early detection

The Axios compromise was not a long, slow burn. Investigations suggest the malicious versions were available on npm for roughly three hours between late Sunday night and the early hours of Monday or Tuesday, depending on time zone.

StepSecurity and other firms noted that the attacker had seeded the ecosystem with a clean version of the malicious dependency about 18 hours before attaching the weaponized variant to Axios. That move appears to have been designed to build a benign history for the package and avoid tripping automated anomaly detectors when the dependency suddenly appeared.

Once the infected Axios releases went live, the trojan performed extensive reconnaissance on each system where it ran: scanning directories, listing running processes, enumerating disks and then shipping that information back to the attacker’s server. All of this happened behind the scenes during what, to developers, looked like a routine dependency installation.

Thanks to coordinated response from the maintainer, npm and multiple security vendors, the malicious versions were pulled within hours. Yet, as several researchers and Google’s own team stressed, a short exposure window is not the same as low risk when the target is a library with tens of millions of weekly downloads.

Impact on developers, crypto projects and end users

From a practical standpoint, the most direct victims of the Axios incident are developers and build environments that installed the malicious versions. Anyone who ran an installation or build that pulled in axios@1.14.1, axios@0.30.4 or plain-crypto-js@4.2.1 with scripts enabled must assume the system could be fully compromised.

For projects in the cryptocurrency space—wallets, centralized and decentralized exchanges, DeFi dashboards, trading bots and Web3 frontends—the stakes are particularly high. Many of these systems depend on Axios to talk to blockchain gateways, APIs and backend services, and they often manage sensitive secrets such as private keys, API credentials and user data.

If a developer workstation or CI agent in such a project was infected, attackers could have gained not only the secrets stored locally but also access to repos and deployment pipelines. With that, they might inject malicious code into future releases, compromise end users indirectly or reroute funds.

By contrast, users who simply run finished applications in their browser are in a better position: the RAT was delivered during installation and build steps, not during runtime in the browser. So visiting a site that uses Axios for client‑side calls does not, by itself, trigger the attack. The risk concentrates on those who installed the affected npm packages.

Immediate steps developers should take

Security teams and maintainers have been clear: if there is any chance your systems pulled in the compromised Axios or plain-crypto-js releases, treat those hosts as fully untrusted until investigated. That means more than just bumping a version number.

Concrete actions recommended by researchers and vendors include:

• Audit your dependencies and lockfiles: Search for axios@1.14.1, axios@0.30.4 and plain-crypto-js@4.2.1 in package-lock.json, pnpm-lock.yaml, yarn.lock and CI logs; see how to fix them safely.
• Upgrade to verified safe versions: Move to clean Axios releases (for example, the immediately subsequent patched tags recommended by the maintainers) and ensure your lockfiles are regenerated.
• Rotate credentials aggressively: Assume any secret present on affected machines or pipelines—cloud API keys, npm tokens, SSH keys, deployment keys, .env variables—may have been stolen and rotate them.
• Rebuild compromised systems: Where possible, redeploy build agents, CI runners and developer workstations from trusted images rather than trying to clean them in place.
• Block C2 infrastructure: Add sfrclak.com and 142.11.206.73 to firewalls, DNS blocklists and EDR rules.
• Hunt for artefacts: Check for the filesystem paths and temporary files associated with the RAT on macOS, Windows and Linux hosts.

Several security companies have advised organizations that installed the tainted versions to presume compromise by default. In other words, proceed under the assumption that attackers had access, and work systematically through incident response steps rather than hoping the malware did nothing.

Broader lessons for software supply-chain security

Beyond the immediate triage, the Axios incident has reignited debates about how the broader ecosystem handles trust, identity and distribution in open source. It illustrates how a single library maintainer account can become a linchpin for the security posture of countless organizations.

Several themes have emerged from post‑mortems and vendor analyses:

• Legacy tokens are a liability: Old npm tokens can quietly persist alongside newer OIDC‑based workflows. Projects need explicit policies to revoke them once safer methods are in place.
• Automated updates cut both ways: Automatic dependency bumps speed up development but also mean that a malicious release can propagate through ecosystems before anyone notices.
• Dependency scanning is necessary but not sufficient: Static checks and npm audit are useful, yet they struggle against ephemeral behaviour like self‑deleting postinstall scripts.
• Maintainer security is critical infrastructure: Strong MFA, hardware security keys, careful handling of access tokens and regular review of who can publish are now as important as writing good code.

For founders, CTOs and engineering leaders, the Axios compromise is a reminder that supply-chain risk is a strategic issue, not just a technical one. It affects how quickly you can ship, how you design your CI/CD pipelines, and how you balance the convenience of open source with the need to verify what you run in production.

Taken together, the compromise of Axios on npm shows how a short‑lived but well‑planned attack can turn a trusted building block of the JavaScript ecosystem into a stealthy conduit for remote access malware. With attackers targeting maintainers and distribution channels as much as end users, keeping software supply chains healthy now depends on tighter controls around publishing workflows, aggressive monitoring for anomalies and a willingness to treat dependencies with the same skepticism once reserved only for external network traffic.