CyCognito Details Axios Supply Chain Attack After Malicious npm Releases Deliver Remote Access Trojan

Related

Iowa’s Cybersecurity Leadership Spotlight

Iowa’s cybersecurity leadership spans enterprise software, financial services, state...

Wyoming’s Cybersecurity Leadership Spotlight

Wyoming’s cybersecurity leadership spans higher education, state government, community...

West Virginia’s Cybersecurity Leadership Spotlight

West Virginia’s cybersecurity leadership spans state government, higher education,...

South Dakota’s Cybersecurity Leadership Spotlight

South Dakota’s cybersecurity leadership spans banking, higher education, consulting,...

Share

CyCognito has detailed a software supply chain incident involving the widely used JavaScript library axios, after threat actors briefly published two malicious package versions to npm following the compromise of a lead maintainer’s credentials. The poisoned releases, [email protected] and [email protected], were designed to deploy a remote access trojan at installation time, creating immediate risk for developer workstations, CI/CD runners, and other environments that resolved dependencies during the exposure window.

Incident Overview

According to CyCognito’s analysis, the malicious axios releases were available on npm for roughly two to three hours before they were removed. During that period, systems that installed either version also pulled a hidden dependency containing a postinstall script, which executed automatically during package installation and triggered malware deployment.

The installation chain delivered platform-specific binaries for Windows, macOS, and Linux. Once executed, the malware established communication with attacker-controlled infrastructure and attempted to reduce forensic visibility by removing elements from the installed package path. The company said the attack affected both the current 1.x branch and the legacy 0.x branch, significantly broadening the potential victim pool.

That matters because axios remains one of the most widely used HTTP client libraries in the JavaScript ecosystem, with use across front-end applications, back-end services, internal tooling, and automated development workflows. This was not simply a case of a vulnerable dependency entering the ecosystem. It was an active installation-time compromise capable of giving attackers footholds inside trusted engineering environments.

Scope of Exposure

The affected population includes organizations or developers that installed [email protected] or [email protected] during the March 31 exposure window. Because the compromise executed during dependency installation, the risk extends beyond internet-facing applications and production systems. Impacted assets may include developer laptops, ephemeral CI runners, containerized build environments, and internal automation systems that rebuilt or refreshed Node.js dependencies during that time.

This distinction is important because the issue is not limited to whether the malicious package made it into a production release. Any system that fetched and processed the affected versions should be treated as potentially exposed, even if the resulting build was never deployed. In enterprise environments, that can place cloud credentials, source-control secrets, SSH material, package tokens, and deployment keys at risk.

CyCognito also noted that observed exposure in its own data spanned multiple sectors, with consumer and industrial organizations among the most represented in its sample. Still, the nature of the package and the delivery mechanism make this a broad cross-sector supply chain issue rather than an industry-specific one.

Strategic Implications

For security leaders, the incident reinforces how software supply chain attacks can move upstream of runtime and into the development workflow itself. In this case, the infection vector was dependency installation, which means the core question is not simply whether malicious code reached production, but whether an attacker gained execution inside a trusted engineering environment.

That creates a different response challenge. Exposure may include credential theft, pipeline compromise, and broader trust issues across internal software delivery systems. It also complicates investigation. CyCognito said the malicious chain attempted to remove traces after execution, meaning defenders should not rely on a clean-looking package directory as evidence that a system was unaffected. Instead, security teams need to review lockfiles, dependency-resolution logs, CI/CD histories, and other installation telemetry to determine whether the affected versions were ever fetched.

Recommended Response Priorities

  1. Identify exposure with precision. Review package-lock.json files, build logs, CI job histories, and dependency records for evidence of [email protected], [email protected], or the associated malicious dependency cited by CyCognito.
  2. Assume credential exposure where affected systems had access to sensitive material. Rebuild impacted hosts or runners from a known-good baseline, and rotate secrets that were present or reachable at install time, including cloud credentials, SSH keys, package tokens, and CI/CD secrets. CyCognito has published additional guidance on the incident and its implications for enterprise exposure monitoring.
  3. Reduce future build risk by limiting unnecessary install-time script execution in automated environments and hardening dependency handling practices in CI/CD. In this case, CyCognito specifically pointed to measures such as npm ci –ignore-scripts in appropriate build scenarios to reduce exposure to malicious postinstall behavior.