Security
Axios npm Incident: Phantom Dependency, RAT Dropper, and Supply-Chain Lessons
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.
Primary links for fact-checking: see Primary sources & security bridge below (Microsoft, Google/Mandiant, GitHub OIDC, CISA).
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. Using TCP port 8000 (not the usual 80/443 web defaults) was a practical detection lever: egress rules and proxy logs tuned only for standard HTTP/S ports miss less, so odd high ports during npm install became a high-value signal for scanners and SOC tooling. npm pulled the packages after automated tooling flagged suspicious outbound traffic. If you installed either bad version, treat the environment as compromised: invalidate CI and registry secrets first (see If you were affected), 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—so a normal code review of the GitHub tree would show no such dependency. The risk is that the published npm tarball can still list and bundle the package: what you see in git and what npm pack would expand are not guaranteed to match. plain-crypto-js was dangerous precisely because it did not have to appear in upstream source review; it lived in the registry artifact, poisoning build outputs for anyone who trusted the semver bump.
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.
Attack timeline (summary)
- ~March 30, 2026: **`plain-crypto-js@4.2.0`** published—reported as a **benign-looking** line to seed registry history before the axios drops.
- ~March 31, 2026: **`axios@1.14.1`** and **`axios@0.30.4`** published from the **compromised maintainer path**; **`plain-crypto-js@4.2.1`** **`postinstall`** runs on **`npm install`**, deploying the **RAT** dropper and **C2** beaconing (including **port 8000**).
- ~April 1, 2026: **npm** and ecosystem tooling **detect** anomalous traffic; **malicious axios versions** **unpublished**; **`plain-crypto-js`** placed under **security hold** / stub replacement per registry response reporting.
Trusted Publishing vs. manual publish (integrity signal)
When comparing **known-good** axios lines to the **malicious** releases, vendors and analysts highlighted provenance from OIDC Trusted Publishing—not as a guarantee for every package, but as the first diff operators should automate in allowlisting and CI gates:
| Axis | Legitimate axios releases (reported) | Malicious 1.14.1 / 0.30.4 (reported) |
|---|---|---|
| Publish path | Tied to GitHub Actions + OIDC Trusted Publisher flows where configured | Shipped via compromised maintainer / manual-style npm publish, bypassing that bound CI path |
| Provenance / attestations | Expected integrity signals (OIDC-bound publication metadata) present in vendor comparisons | Missing or inconsistent with the OIDC-bound pattern—useful red flag once compared side-by-side |
| Practical check | Treat “no provenance where peers have it” as a gating signal for high-impact dependencies; do not rely on semver or README alone. | |
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. attribution reflects vendor and open-source reporting—threat labels can evolve with new evidence.
postinstall should be treated as executable trust boundaries, not routine metadata.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 only in the published tarball—evade cursory repo review and can slip past teams that never
npm packor diff registry metadata against Git. postinstallscripts 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
| Area | What happened | Operational implication |
|---|---|---|
| Compromised versions | axios@1.14.1, axios@0.30.4 | Treat any touched environment as potentially compromised |
| Attack chain | Phantom dependency plain-crypto-js@4.2.1 -> postinstall -> RAT dropper -> C2 | Lock install-time script behavior and monitor egress during builds |
| Affected OS scope | Windows, macOS, Linux payload paths reported | Incident response must include cross-platform endpoint review |
| Integrity signal gap | Malicious packages lacked expected OIDC Trusted Publisher binding | Enforce provenance policy checks before internal allowlisting |
| Registry response | npm unpublished bad versions; security hold/stub applied | Registry takedown reduces spread but does not remediate prior installs |
| Attribution (reported) | Microsoft linked activity to Sapphire Sleet | Use for prioritization; do not delay containment waiting on attribution certainty |
| Known-good fallback | Example safe lines: 1.14.0, 0.30.3 after independent verification | Rebuild from clean caches with checksum/provenance validation |
| C2 egress signal | sfrclak.com:8000 (non-standard port vs 80/443) | Tune proxies/EDR for install-time egress; port 8000 stood out in reporting |
If you were affected
If axios@1.14.1 or axios@0.30.4 was installed on a machine or in a pipeline:
- Assume compromise for that environment until proven otherwise.
- Invalidate secrets in priority order:
~/.npmrc/ project.npmrcand CI-stored npm automation tokens (publish and read scopes); cloud provider access keys and deployment credentials on any runner that rannpm install; then API keys, SSH keys, and generic CI vault secrets. Rotation here means revoke + re-issue, not only changing passwords. - 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.
- Rebuild from clean caches where practical; review lockfiles and transitive trees for unexpected packages.
- Preserve telemetry (DNS, proxy, EDR, CI logs) if you are conducting a formal investigation.
What to watch next
- npm and ecosystem postmortems — How the maintainer credential was obtained (phishing, device theft, session hijack, etc.) and hardening guidance.
- Trusted Publishing — Pressure for mandatory OIDC-bound releases on high-impact packages and token rotation policies.
- Install-time monitoring — C2 beacons,
postinstallabuse, and lockfile diff tooling in CI. - Attribution updates — Whether other vendors corroborate or refine Sapphire Sleet naming for this campaign.
- 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.
Primary sources & security bridge
Vendor advisories and official docs first; use IoC posts for detection engineering, OIDC docs for preventive architecture.
- Microsoft — Sapphire Sleet / axios compromise (threat analysis & mitigation): Mitigating the axios npm supply-chain compromise
- Google Cloud (Mandiant) — threat intelligence & IoCs (e.g. WAVESHAPER.V2): North Korea–linked activity targeting axios npm package
- GitHub Docs — OIDC / deployment hardening (Trusted Publishing alignment): About security hardening with OpenID Connect
- CISA — supply-chain alert (axios / npm): Supply chain compromise impacts axios Node Package Manager
Bridge to this article: Use Microsoft and Mandiant for TTPs, IoCs, and enterprise detection; use CISA for org-wide executive and patching framing; use GitHub OIDC docs to tighten the publish path that this incident bypassed. For a parallel third-party tool breach narrative, see Vercel / third-party compromise — security bridge.
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. Revoke npm and cloud credentials that may have lived on the box or in .npmrc first, then 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.
