The Axios JavaScript library, one of the most downloaded packages in the npm ecosystem with around 100 million weekly installs, has been at the center of a carefully orchestrated software supply chain attack. The incident was not caused by a coding flaw, but by a highly targeted social engineering operation that compromised the maintainer’s credentials and allowed attackers to publish trojanized Axios releases.
How the Axios maintainer was targeted: advanced social engineering, not code exploits
The primary attack vector was the compromise of the maintainer’s npm credentials through a multi-stage social engineering campaign, rather than exploitation of a technical vulnerability. According to incident analyses, the adversaries impersonated the founder of a real, well-known company, meticulously cloning the person’s identity, communication style, and corporate brand.
To build credibility, the attackers invited the maintainer into a fraudulent Slack workspace that mimicked a genuine corporate environment. The workspace featured realistic branding, channels aligned with typical engineering and product topics, and even links to legitimate LinkedIn posts. This helped lower the maintainer’s guard by presenting a convincing business context.
The next stage involved a scheduled meeting via Microsoft Teams. During the fake call, the maintainer saw what appeared to be a system error message, allegedly related to an outdated component on their workstation. The “fix” for this problem was an installer presented as a legitimate update. In reality, it silently deployed a remote access trojan (RAT), giving the attackers persistent access to the machine.
From RAT access to malicious Axios versions: the full compromise chain
With a RAT running on the maintainer’s system, the attackers were able to steal npm authentication tokens used for publishing Axios releases. These stolen credentials were then abused to push two malicious versions of Axios to the npm registry: 1.14.1 and 0.30.4.
Both versions included a malicious component tracked as WAVESHAPER.V2. While technical details of this payload vary by report, such components typically enable data exfiltration, command execution, or further lateral movement once they land in downstream environments. Because Axios is widely used in both frontend and backend applications, such a payload can potentially propagate into server-side systems, CI/CD pipelines, and end-user environments.
Threat intelligence teams note that the tactics used in this operation are consistent with the activity of the UNC1069 / BlueNoroff group, a North Korean-linked cluster historically focused on cryptocurrency platforms, venture funds, and high-profile individuals. The broader social engineering and malware toolkit has been documented by researchers from Huntress and Kaspersky under the codename GhostCall.
Shift in targeting: from crypto founders to open-source maintainers
A significant development in this case is the apparent strategic shift in targeting. Instead of exclusively going after crypto founders or financial sector executives, the GhostCall campaign has now been observed focusing on maintainers of high-impact open-source projects.
This change dramatically amplifies potential impact. By compromising a single maintainer with publish rights to a widely adopted dependency, attackers gain the ability to poison a vast downstream ecosystem. In JavaScript development, where projects commonly rely on dozens or hundreds of npm packages, the compromise of a core library like Axios can quietly propagate through:
• Direct dependencies — applications that explicitly import Axios in their code.
• Transitive dependencies — other libraries that embed Axios under the hood, extending the blast radius to organizations that may not even realize they are indirectly dependent on Axios.
This dynamic mirrors past supply chain incidents such as the event-stream and ua-parser-js compromises in npm, or more recent cases like the xz utils backdoor in the Linux ecosystem, and highlights how challenging it is to accurately assess exposure in modern dependency trees.
Why this Axios attack is a wake-up call for JavaScript supply chain security
The Axios incident underscores structural risks inherent in today’s JavaScript ecosystem. Automated dependency resolution, default trust in central registries, and practices like auto-updating dependencies can all magnify the impact of a single compromised package.
When an attacker gains access to a maintainer’s publishing pipeline, the traditional defenses that focus solely on vulnerability scanning or code review may be insufficient. The core of the problem becomes integrity of the release process rather than code quality alone. This aligns with a broader industry trend: regulators, standards bodies, and initiatives such as SSDF (Secure Software Development Framework) and SLSA (Supply-chain Levels for Software Artifacts) increasingly emphasize supply chain and build pipeline security.
Maintainer response: hardening publishing pipelines and identities
Following detection of the compromise, the Axios maintainer implemented several significant security measures aimed at restoring trust and reducing the risk of future incidents:
• Full reset of devices and access credentials. Physical machines, npm accounts, and other critical access points were rebuilt or rotated to eliminate any hidden footholds left by the attackers.
• Adoption of “immutable releases”. Once a version of Axios is published, it can no longer be retroactively modified. This helps prevent silent replacement of previously released artifacts and aligns with best practices for artifact integrity.
• Migration to OIDC-based publishing. Instead of relying on long-lived static tokens, the maintainer adopted OIDC (OpenID Connect) flows to issue short-lived, scoped credentials. This reduces the value of stolen tokens and constrains where and when they can be used.
• Hardening of GitHub Actions and CI/CD pipelines. The project’s automation now follows stricter least-privilege policies, tighter scoping of secrets, stronger integrity checks on build artifacts, and more explicit validation of actions executed within the pipeline.
These changes mirror a growing industry consensus that open-source security must extend beyond code review to include the entire software development lifecycle and supply chain.
The Axios compromise demonstrates that even mature, widely trusted open-source projects are vulnerable to targeted social engineering and supply chain manipulation. Organizations and developers should respond by reinforcing key controls: enforce multi-factor authentication on all critical accounts, prefer hardware security keys where possible, apply least-privilege principles in CI/CD, regularly scan and review dependencies using specialized tools, and invest in training teams to recognize sophisticated social engineering campaigns. Treating trust in open source as a security boundary is no longer sufficient; building resilience into identities, pipelines, and dependency management is essential to limiting the impact of the next supply chain attack.
