Skip to content
HACKTECH
Supply chainReported Published 3 sources

Hijacked axios maintainer account used to publish npm releases that installed a RAT

On 31 March 2026 an attacker used the hijacked npm account of axios's lead maintainer to publish axios 1.14.1 and 0.30.4, which added a malicious dependency, plain-crypto-js@4.2.1, whose postinstall hook installed a cross-platform remote access trojan. The axios post-mortem says the attacker obtained the npm credentials through a targeted social engineering campaign and RAT malware on the lead maintainer's computer, and the maintainer said in the issue thread that 2FA was enabled on the account; the malicious versions were live for about three hours. Google Threat Intelligence Group attributed the activity to UNC1069, which it describes as a financially motivated North Korea-nexus actor, citing its WAVESHAPER.V2 backdoor and infrastructure overlaps.

  • axios
  • npm
  • maintainer account takeover
  • social engineering
  • remote access trojans
  • UNC1069
  • North Korea

What the sources report

  • Post-mortem timeline (UTC): plain-crypto-js@4.2.0 published 30 March 05:57; axios@1.14.1 published 31 March 00:21 and axios@0.30.4 around 01:00; malicious axios versions removed 03:15 and plain-crypto-js 03:29. GTIG gives an exposure window of 00:21 to 03:20 UTC.
  • The post-mortem says the social engineering campaign against the lead maintainer began about two weeks before 31 March; in the thread the maintainer described someone masquerading as a company founder using a cloned likeness, an invitation to a Slack workspace, a Microsoft Teams meeting and a message that something on his system was out of date, which led him to install the RAT.
  • The attacker used the hijacked account to delete community issues reporting the compromise (axios post-mortem); GTIG says the account's email address was changed to an attacker-controlled one.
  • axios source code was not modified: plain-crypto-js@4.2.1 ran setup.js through a postinstall hook, then deleted itself and replaced the tampered package.json with a clean copy stored as package.md (Unit 42, GTIG).
  • On Windows the dropper copied the legitimate PowerShell binary to %PROGRAMDATA%\wt.exe and used it to run a downloaded PowerShell RAT; macOS received a Mach-O binary at /Library/Caches/com.apple.act.mond and Linux a Python RAT at /tmp/ld.py; all variants beacon every 60 seconds to sfrclak[.]com on port 8000 (GTIG, Unit 42).
  • Unit 42 and GTIG give 1.14.0 and 0.30.3 as the last safe versions; the axios team wiped the lead maintainer's devices, reset all credentials and plans immutable releases and OIDC-based publishing (axios post-mortem).

What it means for your organisation

The maintainer said the npm account had 2FA, but malware on his own computer, installed after a staged meeting and a fake update prompt, gave the attacker what was needed to publish. According to the post-mortem, projects already pinned to a clean version that did not run a fresh install during the roughly three-hour window were unaffected, which is what lockfiles and a delay before adopting new releases are for. The post-mortem calls publishing directly from a personal account 'a risk that could have been avoided', and the team plans OIDC-based publishing and immutable releases.

What we check

  • Search all lockfile types and build caches for axios 1.14.1 or 0.30.4 and plain-crypto-js, and review CI logs for installs between 00:21 and 03:20 UTC on 31 March 2026.
  • Check developer endpoints and runners for the platform artefacts (wt.exe in ProgramData, com.apple.act.mond, /tmp/ld.py) and for 60-second beaconing to port 8000.
  • Test whether CI installs use --ignore-scripts, exact version pins and an internal registry that serves only approved versions.
  • Run a social engineering exercise for engineers and maintainers that mimics a fake founder or partner meeting ending in a required software update.
  • Review how your own packages are published: from personal machines with long-lived tokens, or from CI with OIDC trusted publishing and release approval.

Sources

Services that cover these checks

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

  • Social engineering assessment

    Phishing, vishing and physical pretexting run against your staff, help desk and finance team, only under written authorisation that names the targets, pretexts and limits. Results are reported by channel and pretext, never by name: how far a convincing approach got, how many people reported it and how long the first report took to reach someone who acted.

    Duration: 2 to 4 weeks including campaign preparation

  • Secure development training

    Hands-on workshops for engineers, run against a deliberately vulnerable copy of a codebase like yours. Developers exploit each bug before they fix it, so they have seen the attack their fix has to stop, and review real pull requests for the same bugs.

    Duration: 1 to 3 days on site or remote

  • Application security audit

    A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.

    Duration: 5 to 15 working days, depending on codebase size

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works