Application security , Third-party code Axios breach shows why software supply chains need zero trust May 14, 2026 Share By Oludolamu Onimole (Adobe Stock) 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: Axios npm supply chain attack: Malicious updates add remote access trojan Axios maintainer’s post mortem confirms social engineering by UNC1069 The Axios npm breach taught us the need for a personal zero-trust OpenAI’s macOS app-signing process hit by axios supply chain attack 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. Use OIDC tokens or ephemeral credentials instead of long-lived npm tokens Rotate or revoke keys immediately if compromise is suspected. In short, the publisher’s identity must be as secure as a customer’s. 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 Oludolamu Onimole Oludolamu Onimole is a cyber operations analyst with the University of Glasgow. Related Application security Trusted by default: The npm attack pattern security teams miss Mohit Bansal May 13, 2026 Developers are now the prime target in evolving npm supply chain attacks. Application security Android 17 enhances security with scam call protection and theft deterrence SC Staff May 13, 2026 Google is expanding protections against caller ID spoofing, partnering with banking apps like Revolut, Itaú Unibanco, and Nubank to automatically terminate scam calls. Identity ‘Mini’ Shai-Hulud attack compromises hundreds of npm, PyPI packages Steve Zurier May 12, 2026 Teams warn the latest Shai-Hulud wave weaponizes trusted OIDC tokens to bypass package integrity checks. Related Events Cybercast CISO Stories: AI Security (Blackhat Preview) – Arctic Wolf Thu Jul 9 Cybercast Protecting Application User Data for Better Privacy, Governance, and Compliance On-Demand Event Cybercast The Next Evolution of Application Security: AI- Accelerated DevSecOps On-Demand Event Get daily email updates SC Media's daily must-read of the most current and pressing daily news Business Email By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy . Subscribe Related Terms Banner Browser Cache Cramming Common Gateway Interface (CGI) Client Cookie DLL Injection Dynamic Link Library You can skip this ad in 5 seconds