TLDR

SignalStack Tech Report · April 2, 2026 · Security / Supply Chain / Incident Response

Why this is on SignalStack (not generic “breach news”): we prioritize incidents where attack mechanics change what developers and platforms must do—not only the brand name in the headline. The axios case matters because it chains maintainer-account compromise, a phantom dependency invisible to casual package.json review, postinstall execution on dev and CI, and anti-forensics—the kind of stack that scales across the JavaScript ecosystem.

Two poisoned releases of axios—1.14.1 and 0.30.4—were published to npm in late March 2026. They did not reflect legitimate project changes. A compromised maintainer account shipped builds that pulled in a fake dependency, plain-crypto-js@4.2.1, whose postinstall script deployed a cross-platform remote access trojan (RAT).

The dropper contacted a live command-and-control (C2) endpoint—reported as sfrclak.com:8000—and retrieved second-stage payloads for Windows, macOS, and Linux. npm pulled the packages after automated tooling flagged suspicious outbound traffic. If you installed either bad version, treat the environment as compromised: rotate secrets, reinstall from known-good versions, and follow your incident playbook.

What happened

Axios is one of the most widely used HTTP clients in JavaScript, with on the order of 100 million weekly downloads on npm. On March 30–31, 2026, attackers published axios@1.14.1 and axios@0.30.4 outside the project’s normal release path.

Investigations describe the root cause as compromise of a lead maintainer’s npm account. With publish rights, attackers could bypass the usual GitHub Actions CI/CD flow and ship packages that looked like official semver bumps.

The malicious builds introduced a phantom dependency: plain-crypto-js@4.2.1. Axios never legitimately depended on this package in source control. Its role was to run a postinstall script during npm install, kicking off a RAT dropper. The dropper contacted the C2 host above and fetched platform-specific payloads.

To slow forensics, analysis of the campaign describes the malware removing its own primary artifacts after execution and rewriting package.json to a clean-looking decoy (for example showing 4.2.0 instead of 4.2.1). A benign plain-crypto-js@4.2.0 had appeared roughly 18 hours earlier, likely to build benign publish history and reduce early scanner noise.

Legitimate axios releases tied to OIDC Trusted Publisher flows showed expected integrity signals; the malicious versions lacked that binding, which became a useful indicator once analysts compared metadata.

Security vendors and scanners—including tooling such as StepSecurity AI Package Analyst and Harden-Runner—flagged anomalous outbound connections to C2 infrastructure. npm unpublished the bad axios versions within hours and placed plain-crypto-js under security hold, replacing it with a stub.

Microsoft Threat Intelligence has attributed the campaign to Sapphire Sleet, described as a North Korean state-sponsored group associated with financially motivated and IP-focused operations, with reported impact across sectors including government, finance, retail, and technology. SignalStack note: attribution reflects vendor and open-source reporting—threat labels can evolve with new evidence.

Why it matters

This is not a one-off typo in a lockfile. It is a supply-chain strike against a foundational library: compromise axios, and you touch a huge share of applications, internal tools, and CI runners that run npm install routinely.

Technique stack worth internalizing:

• Maintainer-account takeover plus long-lived tokens can bypass pipeline-centric controls if publishing remains possible outside OIDC-bound flows.
• Phantom dependencies—packages absent from upstream source but present in the published tarball—evade cursory package.json review.
• postinstall scripts remain a high-leverage execution path on developer laptops and build agents.
• Anti-forensics (self-deletion, decoy metadata) raises the bar for post-incident analysis without network and host telemetry at install time.

When a capable actor chains those methods against a top-tier dependency, the blast radius is ecosystem-wide, not limited to a single repo.

Key details at a glance

• Bad versions: axios@1.14.1, axios@0.30.4 (removed from npm after discovery).
• Mechanism: Phantom dependency plain-crypto-js@4.2.1 → postinstall → RAT dropper → C2 (sfrclak.com:8000 reported).
• Platforms: Windows, macOS, Linux second-stage payloads.
• Integrity signal: Malicious releases lacked OIDC Trusted Publisher binding described for legitimate lines.
• npm response: Unpublish of bad versions; security hold / stub on plain-crypto-js.
• Attribution (reported): Microsoft → Sapphire Sleet (DPRK-linked APT naming).
• Safe lines (examples): axios@1.14.0, axios@0.30.3 after verification against trusted sources—not taken from this article alone as sole authority.

If you were affected

If axios@1.14.1 or axios@0.30.4 was installed on a machine or in a pipeline:

1. Assume compromise for that environment until proven otherwise.
2. Rotate credentials and secrets that could have been exposed (API keys, cloud tokens, SSH keys, .npmrc tokens, CI secrets).
3. Pin or downgrade to known-good lines—for example axios@1.14.0 or axios@0.30.3—after verifying checksums and provenance against trusted upstreams.
4. Rebuild from clean caches where practical; review lockfiles and transitive trees for unexpected packages.
5. Preserve telemetry (DNS, proxy, EDR, CI logs) if you are conducting a formal investigation.

What to watch next

1. npm and ecosystem postmortems — How the maintainer credential was obtained (phishing, device theft, session hijack, etc.) and hardening guidance.
2. Trusted Publishing — Pressure for mandatory OIDC-bound releases on high-impact packages and token rotation policies.
3. Install-time monitoring — C2 beacons, postinstall abuse, and lockfile diff tooling in CI.
4. Attribution updates — Whether other vendors corroborate or refine Sapphire Sleet naming for this campaign.
5. Upstream axios — Release process changes and communications to rebuild trust signals.

The SignalStack angle

Beyond the package name: SignalStack treats supply-chain stories as systems problems—identity, publish path, runtime at install, and telemetry—not as moral failure of open source.

What we are not doing: turning this into FUD about all npm packages. What we are doing: naming repeatable controls—OIDC, least-privilege tokens, install-time detection—that teams can actually schedule.

1. Maintainer trust is the real perimeter

The dog that didn’t bark here is the move away from GitHub-bound CI/CD toward a direct npm publish: legitimate axios lines tied to OIDC Trusted Publisher flows showed expected integrity signals, while the malicious releases lacked that binding—evidence that the blast radius came from publish path, not a failed automation story on GitHub alone. Even the best automated pipeline is only as strong as fallback access: long-lived manual npm tokens that can still ship tarballs outside the guarded path.

SignalStack’s read: treat publish credentials as tier-0 secrets—rotation, MFA, scoped tokens, and audit who can ship what—and treat “we have CI” as insufficient if unscoped publish rights remain.

2. Phantom dependencies are a review blind spot

Lockfiles and source trees do not always match the tarball. Defenders need pipeline steps that inspect published artifacts or block unexpected lifecycle scripts for critical dependencies.

3. Attribution is for prioritization, not headlines

State-sponsored labels help risk owners allocate threat-intel budgets—they are not a substitute for patching and rotating secrets today. SignalStack’s signal: assume compromise if you touched bad versions, regardless of who Microsoft names.

Closing note: The metric that matters next is time-to-detect suspicious npm install traffic in your environment—not retweeting the APT name.

Disclaimer: This article is journalism and analysis, not incident-response or legal advice for your organization. Verify versions and vendor guidance from primary sources before production changes.

FAQ

Q Which axios versions were compromised?

A axios@1.14.1 and axios@0.30.4 were the malicious releases identified on npm.

Q What should I do if I installed one of them?

A Treat the system as potentially compromised. Rotate secrets immediately, remove the bad version, and install a known-safe release (for example 1.14.0 or 0.30.3) after verification. Follow your organization’s incident process.

Q How did the attack work technically?

A Attackers used a compromised maintainer npm account to publish axios builds that included a fake dependency, plain-crypto-js@4.2.1. That package ran a postinstall script that installed a RAT dropper, which then talked to a C2 server and fetched platform-specific payloads.

Q Was upstream Axios source code backdoored?

A Reporting indicates the core Axios codebase was not modified in the normal open-source tree. The malicious behavior lived in the published npm artifact and the injected plain-crypto-js dependency executed at install time.

Q Who is attributed to the attack?

A Microsoft Threat Intelligence links this activity to Sapphire Sleet, a North Korean state-sponsored threat actor with a track record of financially motivated and supply-chain–adjacent campaigns. Attribution can be updated as new evidence emerges.