A critical supply chain attack has impacted the widely used JavaScript library Axios following the compromise of its primary maintainer’s npm account. Threat actors used the hijacked account to publish two malicious versions, axios@1.14.1 and axios@0.30.4, which introduced a rogue dependency (plain-crypto-js@4.2.1). This dependency was not part of the legitimate Axios codebase and existed solely to execute a post install script that deployed a cross-platform Remote Access Trojan (RAT).

The attack was highly coordinated. The malicious dependency was staged in advance and later injected into both the current and legacy Axios release branches within a short timeframe, maximizing impact. Because the malicious code resides in a transitive dependency rather than Axios itself, traditional code review or diff-based detection would likely fail to identify the compromise. Furthermore, the malware is designed to remove itself after execution and replace evidence within the package directory, significantly complicating forensic analysis.

Once installed, the dropper script contacts a command-and-control server (sfrclak[.]com) and retrieves a second-stage payload tailored to the operating system. On macOS, it deploys a binary disguised as a system cache daemon; on Windows, it leverages PowerShell executed via a disguised binary; and on Linux, it deploys a Python-based backdoor. These payloads enable remote command execution, data exfiltration, and further payload delivery. Although the malware does not appear to establish persistence by default, its capabilities allow attackers to quickly escalate access or deploy additional mechanisms.

Due to the self-deleting nature of the dropper, identifying compromise requires a combination of dependency analysis, system artifact inspection, and log review. Organizations should examine installed packages and lockfiles for the affected Axios versions, verify whether the plain-crypto-js directory exists or existed, and check endpoints for indicators such as /Library/Caches/com.apple.act.mond, %PROGRAMDATA%\wt.exe, or /tmp/ld.py. Network logs should also be reviewed for communication with the known command-and-control infrastructure. Any confirmed indicator should be treated as evidence of full system compromise.

What You Should Do

If your environment has installed either of the malicious Axios versions, you should assume compromise and respond accordingly. Systems should not be cleaned in place, as the full extent of attacker activity cannot be reliably determined. Instead, affected machines must be rebuilt from a trusted, known-good baseline to ensure complete eradication of any malicious components.

All credentials that may have been exposed on the affected systems must be rotated immediately. This includes npm tokens, cloud provider credentials, SSH keys, API keys, environment variables, and any secrets used within CI/CD pipelines. Special attention should be given to build systems and automation pipelines, as these often have access to highly sensitive credentials and may have executed the malicious package during routine builds.

As part of containment, organizations should block outbound communication to the identified command-and-control domain and associated IP addresses. Security teams should also review logs for suspicious outbound connections, unusual process execution, or signs of data exfiltration during the timeframe in which the malicious packages were available.

For recovery, Axios should be downgraded to a known safe version such as 1.14.0 or 0.30.3, and the malicious dependency should be removed if present. Dependencies should then be reinstalled using safer practices, such as disabling lifecycle scripts where feasible. CI/CD pipelines should adopt secure defaults like npm ci --ignore-scripts to reduce the risk of similar attacks executing automatically in the future.

In the longer term, organizations should strengthen their software supply chain security posture. This includes enforcing strict dependency pinning, auditing both direct and transitive dependencies, and implementing tooling capable of detecting malicious packages in real time. Reducing reliance on implicit trust in package registries and maintainers is critical, as this incident demonstrates how a single compromised account can have cascading effects across thousands of downstream applications.

This attack underscores the growing sophistication of supply chain threats within the open-source ecosystem. By leveraging trusted distribution channels, attackers can achieve widespread access with minimal effort, making proactive monitoring, rapid response, and defense-in-depth essential components of modern cybersecurity strategy.

If you are worried about any of the threats outlined in this bulletin or need help in determining what steps you should take to protect yourself from the most material threats facing your organisation, please contact your account manager, or alternatively get in touch to find out how you can protect your organisation.