A new report from StepSecurity has uncovered a serious supply chain attack involving Axios, one of the most widely used HTTP client libraries in the JavaScript ecosystem. Two versions of the package, [email protected] and [email protected], were found to include a hidden malware mechanism that could silently compromise developer systems across Windows, macOS, and Linux.
What makes this incident particularly concerning is how clean everything appeared on the surface. The affected versions of Axios worked exactly as expected, with no visible changes in functionality or code behavior. There was no malicious code inside the Axios source itself. Instead, the attacker used a more subtle approach by adding a new dependency, [email protected], which had no actual use in the project. Its only purpose was to execute a postinstall script during npm installation.
Once triggered, this script acted as a dropper. It connected to a remote command-and-control server and downloaded a second-stage payload tailored to the operating system. Different payloads were prepared for macOS, Windows, and Linux. It shows that the attack was carefully planned in advance. After execution, the malware deleted its own files and replaced its package configuration with a clean version. This makes it extremely difficult to detect through normal inspection. Even developers who manually checked their node_modules directory after installation would likely see nothing suspicious.
According to the findings, the attacker gained access to the npm account of a lead Axios maintainer and used it to publish the compromised versions. These releases did not go through the project’s usual GitHub-based CI/CD pipeline, which typically uses secure publishing mechanisms. Instead, they were pushed directly using compromised credentials. It allowed the attacker to bypass important safeguards. The two malicious versions were published within a short time gap to target both the latest and older release branches, increasing the chances of widespread impact.
Axios is not a niche package. It is used in frontend applications, backend services, and automated CI/CD workflows. With hundreds of millions of downloads every week, even a short exposure window of a few hours is enough to affect a large number of systems. Any developer who ran npm install or updated dependencies during that time could have unknowingly executed the malicious script.
The impact goes beyond individual machines. If the compromised package was installed on a developer’s system, it could access sensitive data such as SSH keys, API tokens, and cloud credentials stored locally. In the case of CI/CD pipelines, the risk is even higher. These environments often contain deployment secrets and access tokens for production systems. A successful compromise here could allow attackers to move laterally, inject malicious code into applications, or gain control over infrastructure.
The attacker staged the malicious dependency in advance by first publishing a clean version to build trust and avoid suspicion. The actual malicious update was introduced later. This reduces the chances of being flagged by security tools that monitor newly created packages. The use of a dependency that is never imported in the codebase is another key detail. It shows how attackers are increasingly abusing the package installation process itself, rather than modifying application logic.
This incident also highlights a broader issue in the open source ecosystem. Developers often trust widely used packages and update them without much scrutiny. While this trust has enabled rapid development, it also creates a single point of failure. When a popular package is compromised, the impact spreads quickly and silently.
Now after this incident, developers and organizations should adopt stricter dependency management practices. Pinning package versions, reviewing dependency changes carefully, and limiting the execution of install scripts in CI/CD environments can reduce risk.
Anyone who installed [email protected] or [email protected] should assume compromise and take immediate action. This includes rotating all credentials, auditing systems, and rebuilding affected environments from a clean state. Simply removing the package is not enough once the payload has executed.
