The Package Your Developer Trusted: How the Axios Supply Chain Attack Put 100 Million Downloads at Risk
Tuesday 7 April 2026
On March 30, 2026, at some point during an ordinary working day, a threat actor published two versions of Axios to the npm software registry.
Axios is the most widely downloaded JavaScript HTTP client in the world. It handles over 100 million installations every week. It lives inside the code of countless websites, web applications, internal business tools, and SaaS products. If your business uses a web application built in the last decade, there is a meaningful probability it uses Axios.
The two poisoned versions were live for hours. Then they were pulled. And the malware they installed on developer machines deleted its own dropper, leaving the codebase looking completely normal.
Who is accountable for the fact that this was even possible? That question is the one nobody in the open-source ecosystem seems ready to answer. I would like to ask it anyway.
What Actually Happened on March 30
The attack began with account takeover. An unauthorised actor gained control of the npm account belonging to Jason Saayman, the lead maintainer of the Axios project.
The takeover was accomplished via a stolen npm access token. The account’s registered email address was quietly changed to a ProtonMail address controlled by the attacker. With the email changed and the access token in hand, the attacker had full administrative access to one of the most critical accounts in the JavaScript ecosystem.
Two poisoned versions, axios@1.14.1 and axios@0.30.4, were published within 39 minutes of each other, covering both the current and legacy release branches. Neither version has any matching commit, tag, or release in the official Axios GitHub repository.
Both versions contained a single addition to their package manifest: plain-crypto-js@4.2.1, described in npm’s registry as a legitimate cryptography package. It was not. It was a phantom dependency, invented purely to trigger npm’s automatic postinstall hook during installation.
When a developer ran an update and that hook fired, a cross-platform remote access trojan was dropped onto the machine. On Windows, it ran entirely in memory, written to no disk file. On macOS, it hid under a path mimicking an Apple system daemon. On Linux, it ran as a detached background process. After execution, the dropper script deleted itself and swapped in a clean decoy.
The package folder looked normal. The developer saw nothing.
Peter Girnus and Jacob Santos, Trend Micro researchers who conducted a forensic examination of the attack, found that the threat had already reached organisations across government, finance, healthcare, manufacturing, retail, and technology sectors at the time of their investigation. Telemetry confirmed active exploitation during the attack window.
Who Is Accountable for This?
I want to stay on that question for a moment, because the technical analysis is impressive and thorough, but the accountability dimension has received considerably less attention.
The attack succeeded because a single individual’s npm account had no meaningful access controls protecting it beyond a token and an email address. No multi-factor authentication confirmed. No backup account holder. No secondary approval required to publish new versions of a package with 100 million weekly downloads.
The open-source ecosystem runs on trust and contribution. That is not a criticism: it is an extraordinary achievement, and the people who maintain widely used packages often do so for minimal recognition and no pay. But the gap between the responsibility that maintainers of critical packages carry and the security infrastructure they are given to carry it is now a documented attack surface.
npm and GitHub have tools available: OIDC Trusted Publisher bindings that link npm releases to verified CI workflows, two-factor authentication requirements, and enhanced security for packages above certain download thresholds. This attack bypassed GitHub Actions’ OIDC Trusted Publisher safeguards by publishing manually with a stolen token, leaving no cryptographic binding or gitHead reference in the metadata.
Those safeguards existed. The account was not configured to use them.
The question of who bears responsibility for that gap, npm as a registry, GitHub as a platform, the maintainer as an individual, the organisations consuming the package without verification controls, is not one the forensic reports answer. Someone should be answering it.
The Composite Case: A UK Web Agency’s March 30
There is no confirmed, named UK SMB victim in the public record. What there is, based on the sectors confirmed by Trend Micro’s telemetry and the scale of the affected download window, is a high probability that UK organisations were affected. The following composite is built from documented patterns across this attack and similar supply chain incidents.
A small UK digital marketing agency, twelve staff, specialising in e-commerce builds for independent retailers, runs its development pipeline on Node.js. Their standard dependency update cadence is weekly, triggered by their CI/CD system. On March 30, the pipeline ran as scheduled. Axios was listed as a dependency in three client projects currently in active development. The update pulled axios@1.14.1. The postinstall hook ran. The RAT executed. The dropper deleted itself.
Nobody saw anything.
Three days later, a client noticed unusual outbound traffic in their network monitoring. The agency’s developer investigated and found nothing obviously wrong in the codebase. The incident was attributed to a misconfigured analytics tag and logged as resolved.
Two weeks later, Trend Micro’s analysis was published. The agency’s developer read it. Checked the dates. Checked the version history. Went quiet for a while.
The subsequent question was not technical. It was: what credentials were accessible on those developer machines during the exposure window? npm tokens. Cloud provider access keys. SSH keys to client servers. CI/CD pipeline secrets that touch production systems for twelve different retail clients.
That is the blast radius of one poisoned postinstall hook on one developer laptop. And it is why the sectors list in the Trend Micro report, which includes retail and manufacturing, should be read by every UK business that relies on externally built software.
Storm-1175 and Medusa: The Other Attack Vector Running This Week
The Axios story does not exist in isolation. A financially motivated threat group known as Storm-1175 has been running fast-paced attacks targeting vulnerable, internet-facing systems and deploying the Medusa ransomware as the final blow. From the moment it breaks in, attackers can lock down an entire organisation in as little as 24 hours.
Storm-1175 has built its operations around striking during the short gap between when a software flaw is publicly disclosed and when IT teams patch it. The group scans for internet-exposed applications, including file transfer tools and mail servers, still running vulnerable versions. Even a few days of exposure is enough for attackers to gain entry.
In one case, the group exploited CVE-2026-23760, a SmarterMail flaw, a full week before public disclosure. Similarly, CVE-2025-10035 in Fortra’s GoAnywhere Managed File Transfer was exploited one week before official announcement.
Put those two things together: a supply chain attack that lands malware silently through a trusted package, and a ransomware group that moves from first access to full network encryption in under 24 hours. Two different entry points. Two different threat actors. Both active in the same week.
Neither of them required a staff member to click a suspicious link.
That point bears repeating, because a lot of small business security advice still centres on user behaviour. Do not open attachments. Do not click phishing links. Train your staff. All of it useful, none of it sufficient when the threat arrives inside a software update your developer trusted, or through an internet-facing mail server that had been patched last week but not this week.
How to Turn This Into a Competitive Advantage
The organisations that will emerge from this week’s events in a stronger position are not necessarily the ones with the most sophisticated security tooling. They are the ones that can answer a specific question quickly: what software does our business depend on, who built it, and how would we know if it was compromised?
That question is not a CISO’s question. It is a business continuity question. Every director who relies on a web application, an internal tool, or an externally managed platform has a version of it to answer.
If your business can provide clients with a documented Software Bill of Materials (SBOM), or even an honest summary of the dependency audit process your development team or agency follows, that is a differentiator. It is increasingly something that procurement teams in regulated sectors ask about. It is something that cyber insurers are beginning to include in underwriting questionnaires.
The businesses that go to their clients after an incident like this and say “we checked our exposure and we were clean, here is how we know” are building a trust asset. The ones that say “we did not really know where to start” are building a liability.
How to Sell This to Your Board
The Axios incident is a useful board conversation for a specific reason: it removes the human-error argument.
The standard internal security discussion often comes back to staff behaviour. Someone clicked something they should not have. Someone ignored a warning. The implication is that better training would have prevented it. The board nods. The budget goes to awareness campaigns.
The Axios attack did not require any member of staff to do anything wrong. A developer ran a routine dependency update using a package that had been part of the ecosystem for years. The package was legitimate. The version was poisoned. There was no phishing email to identify, no suspicious attachment to reject.
Three arguments for the board conversation:
First, the software supply chain is now a documented attack surface, and organisations have exposure through their suppliers that they cannot control directly but can govern through contract requirements and audit rights.
Second, the business interruption risk from an undetected RAT running in a development environment is not theoretical. If CI/CD secrets, cloud access keys, or client credentials were accessible on affected machines, the downstream exposure may extend beyond the organisation that was directly infected.
Third, the regulatory dimension matters. Under UK GDPR, an organisation that processes personal data is responsible for ensuring appropriate technical measures are in place, including where processing involves third-party tools and software. A supply chain compromise that results in data exfiltration is a reportable breach. The ICO’s position on third-party risk in the supply chain has been clear since the guidance published following the 2021 incident review cycle.
What This Means for Your Business
The honest answer is that if your business relies on externally built software and you have no visibility into your suppliers’ dependency management practices, you already have an exposure you cannot currently measure. That is the starting point, not the conclusion.
1. Ask your agency or MSP directly. If a third party builds or maintains any software your business uses, send a written request this week asking whether their development tooling uses Axios, whether they update dependencies on an automated schedule, and whether they audited their exposure for the March 30 window. Document the response. If they cannot answer clearly, that tells you something important.
2. If you have internal developers, audit the dependency history now. Check your package-lock.json or yarn.lock files for any reference to axios@1.14.1 or axios@0.30.4. If those versions appear in any project updated on or around March 30, treat the machine as potentially compromised and rotate all credentials that were accessible during that window: npm tokens, cloud keys, SSH keys, CI/CD secrets.
3. Block sfrclak[.]com at your network perimeter. This is the command-and-control server used in the Axios RAT campaign. If your firewall logs show any attempted outbound connection to this domain, you have a confirmed infection to investigate.
4. Implement npm ci with the —ignore-scripts flag in your CI/CD pipelines. This blocks postinstall hooks, removing the specific execution path this attack relied on. This is a one-line configuration change that prevents an entire class of supply chain attack vector.
5. For Storm-1175 exposure: audit your internet-facing applications immediately. If your organisation runs SmarterMail or GoAnywhere Managed File Transfer, verify the current version and confirm the patch status against the CVEs identified in Microsoft’s Threat Intelligence report. Apply CISA KEV patches within 72 hours as a standing policy.
Related Posts:
- Your Factory Floor Is Episode 30 at Industrial Scale
- Two Zero-Days, Zero Patches, Zero Excuses: Windows and Fortinet Are on Fire This Week
- South Staffordshire Water: What Happened When SCADA Met Clop
The composite case study in this article is a clearly labelled reconstruction built from documented attack patterns confirmed by Trend Micro’s forensic investigation and the sector telemetry published in their report. No specific named UK organisation is identified or implied.