Why the Axios supply chain attack is a textbook case
In March 2026, the JavaScript library Axios fell victim to a supply chain attack which compromised thousands of developer machines in record time, triggering no alert.
In late March 2026, the npm account of Axios's lead maintainer was compromised. Axios is a JavaScript library downloaded tens of millions of times per week, present in virtually every project that needs to communicate over the internet or with another system — fetching data, submitting information, querying an API, and so on. Axios is a foundational building block in many projects, and that is precisely why it was targeted.
Anatomy of a lightning fast attack
➡️ In under 40 minutes, two malicious versions were published through a notably subtle method: rather than modifying Axios's code directly, which could have raised suspicion and been detected quickly, the attackers introduced a phantom dependency called plain-crypto-js. In the JavaScript ecosystem, a dependency is an external module a project relies on to function. Since projects routinely pull in dozens, sometimes hundreds of dependencies, very few teams inspect them one by one. The attack exploits precisely this blind trust in untested dependencies.
plain-crypto-js never appears in the final application code. Its sole purpose is to execute at the moment a developer installs the library on their machine, an operation as routine as downloading an update. This is the software equivalent of a Trojan horse: no door is forced open; the targets trust an object they have no reason to distrust and they let it in voluntarily, without triggering any alert.
Once triggered, the malicious package silently contacts a remote server, downloads a payload tailored to the operating system (macOS, Windows, or Linux), then self-destructs to leave no trace. In under two seconds, with no visible interaction on the developer's end, the machine is compromised.
Why this attack is as Serious as it is clever
The target is not the end user of the application but the developer themselves, who has access to the source code of the projects they work on, the credentials and access keys used to connect to production servers, deployment environments, private Git repositories and sometimes their clients' systems. Compromising a developer's machine potentially opens a door into the entire company's infrastructure, without ever directly touching any of its own systems.
The exposure window lasted only 2 to 3 hours before the malicious versions were pulled — but Axios is downloaded continuously around the clock, across CI/CD pipelines, developer workstations, and automated build environments. Thousands of machines may have been affected in that window before anyone had time to react.
Who is behind this attack?
Attribution was formally established by Google Threat Intelligence Group (GTIG) and Mandiant, pointing to UNC1069, a North Korea-linked threat actor active since at least 2018. This is not an opportunistic hacker collective: UNC1069 is a state-sponsored actor with financially motivated operations, primarily targeting cryptocurrency firms, software developers and investment funds. Its attacks are well-documented, recurring and of increasing sophistication.
In the Axios case, the malicious dependency had been prepared 18 hours in advance, with three distinct payloads for different operating systems — clear evidence of a planned, targeted operation.
Why this attack vector is particularly dangerous
This is what is known as a supply chain attack: rather than targeting the vault directly, you target the person carrying the money. Instead of attacking a well-protected company head-on, you compromise a trusted component it relies on and let yourself be carried in.
The leverage is enormous. A single compromised component, embedded across thousands of projects worldwide, can reach thousands of targets simultaneously, without ever attacking them directly. The more popular the component, the wider the blast radius. At 100 million downloads per week, Axios was a prime target.
This vector is particularly insidious because it bypasses all conventional security measures. Firewalls, vulnerability scanners, access policies, none of it helps if the compromise occurred upstream, at the moment a dependency was installed on a developer's machine. An organisation can have invested heavily in cybersecurity and still be exposed by a routine update that triggered no alarm.
Best Practices for Protection
Awareness first
A team unaware that this attack vector exists is an exposed team, regardless of its general security maturity. A developer who installs every new version of every dependency without a second thought is an open door and if no one has explained that this risk exists, they have no reason to be suspicious. This is not a question of competence: it is a question of awareness.
Awareness must operate at two levels, technical teams first: understanding that installing a dependency is an act with security implications, not just functional ones. Decision-makers second: understanding that supply chain security is not reducible to an antivirus or a firewall, that it involves organisational and budgetary choices and that without their buy-in, technical teams cannot move forward.
Putting concrete safeguards in place
Not everything should be updated at any time, in any way. This means defining clear rules at the organisational level: an approved list of dependencies, specifying which components can enter projects, in which versions and which versions are locked, intended for the technical team. Concretely, once a dependency version has been validated and approved, it does not change without an explicit decision. New versions published to the public registry are not followed automatically. This slows development cycles but drastically reduces the attack surface.
GitLab makes it possible to set up a private registry that acts as an internal mirror: 1. Versions can be analysed there; 2. Those deemed safe are archived; 3. Developers are briefed to install and use only those versions, rather than pulling from public registries.
➡️ This is a concrete, accessible measure for most teams, one that genuinely changes the picture in the event of an incident on a public package.
Protection has a cost: move slower to move safer
This is a deliberate trade-off: supply chain security cannot be improvised and it carries a real cost in time, in organisation, in infrastructure.
➡️ Every organisation must make this trade-off according to its own constraints, sector and exposure level. There is no universal answer. ➡️ But the trade-off must be a conscious one. The more dependencies a codebase carries, the larger its attack surface. It takes only one compromised dependency out of a thousand to compromise the whole. Choosing to move slower in order to move safer means accepting a constraint today to avoid a crisis tomorrow. Not making that choice is also a decision, provided it is made knowingly and not simply by default.
A decision that belongs to leadership
Awareness and technical safeguards are not enough if the decision to implement them does not come from the right level. Defining a dependency policy, allocating time to maintain it, investing in a private registry, these are decisions that commit the organisation, not just the technical team. The first step is to put the topic on the table with the right stakeholders and ensure that decision-makers understand what they are actually deciding.
For further reading, the CISA and NIST have jointly published a reference guide on defending against software supply chain attacks, a solid resource for structuring an organisational approach to the issue.
Checking your exposure
If your internal or client projects use Node.js/npm, the recommendation is clear: if versions 1.14.1 or 0.30.4 of Axios were installed between 31 March and 1 April 2026, the machine in question should be considered compromised. Credentials and access keys should be rotated and depending on the level of exposure, a full system reinstall should be considered.
The Sigilence team is available if you think you may be affected.