Axios npm Attack and Fake Claude Apps Expose a New Software-Trust Problem

The March 2026 Axios incident and SilverFox’s fake-Claude campaign used different delivery methods, but their central tactic was the same: make malware look trustworthy. One attack abused a legitimate npm maintainer account and a widely used software dependency; the other impersonated an AI product that employees might reasonably install for work.

Neither incident shows that the legitimate Axios library or Anthropic’s Claude product was inherently malicious. The compromise affected specific Axios releases, while the SilverFox operation used counterfeit installers.

What happened to Axios on March 31, 2026?

An attacker took over the npm publishing access associated with a lead Axios maintainer and published two poisoned versions of the package: axios@1.14.1 and axios@0.30.4. Both releases introduced the hidden dependency plain-crypto-js@4.2.1, which was not used as part of Axios’s normal functionality. Its purpose was to run malicious installation code.

That installation script contacted attacker-controlled infrastructure and downloaded a platform-specific remote-access trojan for Windows, macOS, and Linux. As a result, a routine package installation could become the first step in a broader compromise.

The affected versions were available for approximately three hours. Google Threat Intelligence Group recorded activity between 00:21 and 03:20 UTC on March 31, while other incident reporting describes a similar two-to-three-hour window. Axios is a high-impact dependency: multiple reports put its npm usage at roughly 80 million to more than 100 million weekly downloads, although the estimates differ by source.

How the maintainer account was abused

The strongest public reporting supports an npm account takeover rather than a flaw in Axios itself. One report says attackers used a long-lived npm access token belonging to the lead maintainer; other reporting describes the event more generally as a compromised maintainer account or publishing credentials.

That distinction matters. The attack crossed the trust boundary between a maintainer’s publishing authority and npm’s release pipeline. Because the releases were published through a legitimate account, downstream developers and automated systems had fewer reasons to treat them as suspicious.

What the malicious dependency did

plain-crypto-js@4.2.1 was disguised as a normal package dependency but existed to execute a postinstall script. The script contacted a command-and-control server and retrieved a second-stage payload tailored to the host operating system.

The incident therefore did not require developers to download an obviously suspicious executable. The trigger could be an ordinary dependency update, a CI build, or an automated

npm install

Was BlueNoroff responsible?

Attribution is not settled in the material available here. Some reporting links the operation to North Korea-linked actors, including BlueNoroff or related clusters, while Microsoft attributed the compromise to Sapphire Sleet.

Those assessments should not be presented as a single confirmed conclusion. Code, infrastructure, and operational similarities can provide an attribution lead, but they do not by themselves prove which group conducted the attack. The defensible conclusion is that the Axios compromise involved a hijacked maintainer account, poisoned releases, and a cross-platform RAT; the actor behind it remains disputed across public assessments.

How SilverFox used fake Claude applications

SilverFox followed a different route into organizations: it distributed counterfeit Claude applications for Windows, macOS, and Linux. The campaign targeted organizations in industrial, consulting, trade or commerce, and transportation sectors across India, Indonesia, South Africa, and Russia.

The fake applications were impersonations of Anthropic’s Claude brand, not legitimate Claude installers. Their effectiveness depended on a believable workplace scenario: an employee searches for an AI productivity tool, downloads what appears to be a familiar application, and installs malware instead. Kaspersky reporting described the campaign as part of SilverFox activity observed in multiple waves since December 2025.

From tax-themed phishing to AI lures

The campaign also built on earlier tax-themed phishing. In January and February 2026, researchers recorded more than 1,600 malicious emails that posed as official tax-audit notices or claimed to contain lists of tax violations.

The delivery mechanism evolved, but the trust signal stayed familiar. Tax notices create urgency and authority; a branded AI assistant creates relevance and convenience. Both can encourage users to open an attachment, download an archive, or install software before verifying its source.

SilverFox used a staged delivery model with separate infrastructure for different phases of the intrusion. That segmentation can make it more difficult for defenders to block or identify the complete attack chain from a single domain or indicator.

The common lesson: trust is part of the attack surface

The Axios and SilverFox campaigns targeted different trust relationships:

• Maintainer trust: Axios releases appeared to come through an authorized npm publisher.
• Dependency trust: A package manager treated the malicious dependency as part of a normal installation path.
• Brand trust: Fake Claude installers borrowed the identity of a recognizable AI product.
• Workflow trust: Developers and employees followed routine actions—updating dependencies or installing productivity software.

The Axios case demonstrates why a short exposure window can still be dangerous. Package installations and CI jobs can run automatically, so the number of systems reached is not limited to people who manually inspect a release. The SilverFox case shows the same principle from the endpoint side: rapidly adopted software categories give attackers credible new lures.

What organizations should do now

For the Axios incident, audit lockfiles, package manifests, build logs, caches, and dependency inventories for axios@1.14.1, axios@0.30.4, and plain-crypto-js@4.2.1. Any machine that installed an affected version during the exposure window should be investigated for downloaded payloads, unauthorized persistence, and exposed credentials. Advisories specifically recommend treating affected installations as potentially compromised.

For AI software, require employees to obtain desktop applications through approved channels, verify the publisher and download domain, and block or quarantine unapproved installers. For npm publishing, phishing-resistant multifactor authentication, short-lived or tightly scoped credentials, release provenance, lockfiles, and review of dependency changes can reduce the chance that one compromised account becomes a supply-chain event.

The broader control is verification at every trust boundary. A familiar package name is not proof that every release is safe, and a familiar product name is not proof that every installer is genuine.