Axios breach shows why software supply chains need zero trust

COMMENTARY: Axios announced that it had been subject to a breach allegedly perpetrated by North Korean hackers. According to Wiz, axios is present in about 80% of cloud and code environments and is downloaded more than 40 million times a month. This of course, sent many companies into a frenzy as it is commonly used in many infrastructure environments. This is especially concerning, given that four other major open-source projects were compromised in March 2026 alongside axios. 

Axios’ March 2026 compromise was attributed to a hijacked maintainer account used to slip a hidden RAT into npm installs. This mirrors Business Email Compromise (BEC) attacks as exploited trusted identities, not code flaws. In a BEC attack, attackers impersonate an executive to trick staff; in axios, they hijacked the developer’s account so every npm install ran malicious code. At this point, it is apparent that defending code content is not enough if we let attackers into trusted channels. 

The familiar trick: BEC as identity failure 

Business Email Compromise attacks and its persistent success year-on-year have long shown the danger of trusting identity, with over $2.5 billion lost in 2024 alone, according to an FBI report. In a typical BEC, criminals gain access to a legitimate inbox or spoof a boss’s email to redirect funds. For example, an engineering firm fell victim when attackers quietly set a mail rule to forward invoices and then emailed a fake bank account — almost siphoning off millions with no malware needed.

Related reading:

The attack vector wasn’t a technical flaw, but users trusting the sender’s identity and context. Filters and training did little because the email looked legitimate and appeared to follow due, expected processes. The core failure: organizations treated verified senders as inherently safe. 

Axios: The same playbook in our toolchain 

On March 31, 2026, something similar happened in the JavaScript ecosystem. Attackers hijacked the npm credentials of the axios maintainer and released trojanized versions of axios (v1.14.1 and 0.30.4). Critically, the axios source code wasn’t even altered; instead a malicious dependency, plain-crypto-js, was injected and the maintainer’s email account was briefly updated to an attacker-controlled proton email. NPM’s installer then ran an obfuscated postinstall script that dropped a cross-platform RAT on victims’ systems. This resulted in every project installing or updating to that version axios a potential breach, even on Windows, macOS or Linux. 

A broken trust model 

Both scenarios exploit implicit trust. In BEC, no one questions the “from” line or payment urgency and most do not even conduct secondary verifications. In axios, developers never suspect a popular library has been weaponized, because the npm registry and package managers trust that published updates are safe.

The attackers did not need a software vulnerability in this instance as they only needed to hijack an identity. As Unit42 observes, the axios attackers simply “hijacked an Axios maintainer’s npm account” to distribute a RAT. Similar cases have also been seen like in the SolarWinds installers instance, where Orion updates were trojanized in 2020 by APT actors who “injected malicious code called Sunburst” into signed updates. In each case, organizations installed poisoned software because it came from a trusted source. 

This paradigm shift means: identity = new attack surface, if it was not obvious before. Attackers aim for the administrators of trust (CEOs, maintainers, build systems) rather than software bugs. If they control the identity or identity plane, they control the release and everything in most cases. 

Traditional defenses get it wrong 

Defenders still focus on the wrong layer. In email security, we install spam filters, send out awareness emails, phishing simulations and teach users about suspicious links. In software, we run SAST and DAST tools, scan dependencies for known vulnerabilities, and check code with linters but none of these catch a trusted-but-malicious payload. Axios’s plain-crypto-js was obfuscated and used legitimate registry mechanics, so scanners and code reviews saw only “axios official release.” Even dynamic analysis often runs with dev privileges and cannot prevent a clever post-install hook. 

Just as anti-phishing tools miss a well-crafted impersonation email, code-based defenses can’t verify who published a package. We secured data in transit and at rest, but neglected the trustworthiness of our suppliers who often control critical parts of our infrastructure “by proxy.” 

We must stop repeating the same trust mistake at scale. Four urgent actions can help stop attacks like this in their tracks: 

Continuous maintainer identity assurance: Treat developer accounts as high-value because they are. Require phishing-resistant MFA on all build and registry accounts without exception and where possible, use features like conditional access to ensure that sign-ins are only possible on tenant joined devices for another layer of security. 

Each of these steps must be explicitly adopted. Checking policy boxes (“we have SAST”) is obviously not enough when trust channels are weaponized. The NCSC and others now mandate MFA for all publishing accounts and zero-trust for code pipelines; vendors emphasize pinned versions and OIDC over credential storage. These are precisely the measures we need. 

Sandbox or disable lifecycle scripts: No automatic code execution from untrusted dependencies. Wherever possible, run npm install with scripts disabled (e.g. npm install — ignore-scripts) or inside a hardened container that limits outbound calls. Disable or audit postinstall hooks on critical packages before allowing an update. For example, organizations hit by axios were advised to “disable auto-upgrade features” and require manual review of all updates 

Pipeline-level zero trust: Assume your build pipeline can be breached. Do not let npm or CI have broad secrets. Instead, limit or eliminate storing high-privilege tokens in build environments. For instance, treat CI/CD tokens like passwords — ephemeral and minimal privilege and adopt isolation so that a malicious script in build does not get AWS/GCP keys or SSH creds. (This echoes lessons from the 2021 Codecov breach, where a tampered uploader script exfiltrated CI secrets 

Conclusion 

To conclude, BEC proved years ago that fraudsters exploit who we trust and the process we trust due to its familiarity, not vulnerabilities. The axios hack shows our development ecosystem still has not learned that lesson given that we treated the npm registry as our trusted email provider only to find it abused the same way. 

Until we start defending identities and delivery channels as fiercely as code, every trusted maintainer or automated update is a ticking time bomb and this type of attack will still happen again. 

EDIT: It happened again. Since writing this article, two more attacks have been reported; Daemon tools and LiteLLM have both faced similar issues