The JavaScript ecosystem experienced a significant supply chain incident on 31 March 2026 when two newly published Axios versions were found to contain a malicious dependency. Axios is one of the most widely used HTTP clients in both browser and Node.js environments, with weekly downloads ranging from 80 to over 100 million. The compromise impacted organisations across sectors that rely on the package for service integration and automation. The incident demonstrates the growing frequency and sophistication of maintainer account takeovers in open-source ecosystems.
Axios 1.14.1 and 0.30.4 compromise
Two malicious versions of Axios (1.14.1 and 0.30.4) were published to npm using compromised credentials associated with the lead maintainer’s account (jasonsaayman). Reports confirm that the attacker changed the account’s registered email address to a Proton Mail address and used the npm CLI to bypass the project’s GitHub Actions pipeline, allowing the poisoned releases to appear legitimate. Unlike typical vulnerabilities, no flaw existed in the Axios codebase. Instead, the attacker inserted a fake dependency named [email protected]. This dependency appeared nowhere in the GitHub repository but was introduced solely to execute a post-install script.
Compromise technical details
The attack followed a carefully staged workflow over approximately 18 hours. A clean version of plain-crypto-js was uploaded first to build publication history, then replaced with a malicious variant designed to deploy a cross-platform Remote Access Trojan (RAT). This RAT targeted macOS, Windows, and Linux systems alike. The malicious script fetched second-stage payloads from a command-and-control server. After execution, the malware removed itself and replaced its package.json file with a clean decoy, making post-infection analysis difficult. Safety checks in common build pipelines offered no protection, as the attacker used legitimate maintainer credentials.
Technical and business impact
The compromise introduced a malicious dependency that executed during installation rather than at application runtime. This created risk across any environment that performed npm installs, including developer laptops, CI systems, internal build agents, and production hosts. Analysis from security researchers confirms that the malicious package deployed a cross‑platform Remote Access Trojan that adapted its behaviour based on the operating system. macOS endpoints received a binary placed within the system cache directory. Windows hosts were targeted through a hidden PowerShell execution path. Linux systems received a Python payload placed within the temporary directory. These execution paths enabled follow‑on activity through a command and control server and allowed the attacker to run platform‑specific second‑stage payloads.
The presence of the malicious dependency also created opportunities for credential exposure. Developer machines often store sensitive material such as SSH keys, cloud access tokens, API credentials, and build system secrets. Any system that installed the compromised versions may have inadvertently granted the attacker access to these assets. This extends the potential impact beyond the host machine as access tokens can open pathways to source code repositories and cloud environments. The incident therefore carries a wider risk profile than a typical library‑level vulnerability because installation alone triggered execution of malicious code.
Organisations with automated deployment workflows may have experienced silent compromise if CI runners fetched the malicious releases. This can result in unauthorised access to internal systems, disruption during remediation, and increased incident response workload. Teams distributing downstream packages also face reputational risk where their builds inadvertently propagated a compromised dependency. Dependency audits, credential rotation, and wider environment assurance activities can impose delays on release cycles and increase operational cost. The speed and sophistication of the attack demonstrate the importance of dependency governance across the software supply chain and show how quickly a compromise can affect a broad set of users
How to mitigate the Axios compromise
Any system that installed the compromised versions should be treated as potentially compromised. Credentials commonly stored on developer or build systems should be rotated. This includes npm tokens, cloud access keys, API tokens, and SSH keys.
Organisations can reduce the chance of reintroducing the compromised versions by enforcing fixed versions through npm overrides. It is also sensible to check whether the plain-crypto-js directory exists in node_modules because its presence indicates that the malicious post‑install script executed.
Where any RAT artefact is identified on macOS, Windows, or Linux hosts, those systems should be rebuilt from a trusted baseline. Reviewing supply chain controls such as multi-factor authentication on publishing accounts, scoped tokens, and dependency monitoring will help limit similar incidents in the future.
Closing thoughts
This incident reinforces the importance of treating dependency installation as a privileged operation with potential system-wide consequences. Even organisations with strong internal security controls remain exposed when upstream packages are compromised. The attack on Axios shows how quickly a malicious actor can deploy cross-platform payloads using stolen credentials. Security teams should incorporate continuous dependency monitoring, registries offering stronger attestation, and rigorous version pinning across environments.
How can Sentrium help?
If you would like support assessing exposure, improving supply chain security, or hardening your development processes, please take a look at our penetration testing services. We are always happy to discuss practical steps that help teams improve their security posture.
