Delivered by Trust: What the Axios Supply Chain Attack Means for Security Leaders

TLDR; The Axios supply chain attack highlights how certain initial attack vectors are often overlooked and what security professionals can learn from them. This post explores how these attacks introduce significant risk by exploiting trusted software to impact entire organizations.

On March 31, 2026, the widely used Axios NPM package was compromised in a supply chain attack, leading to the release of malicious versions (1.14.1 and 0.30.4). These versions included a trojanized dependency that executes during installation and deploys platform-specific remote access trojans (RATs) from attacker-controlled infrastructure. Affected systems are at risk of persistent remote access, command execution, data exfiltration, and additional payload delivery.

Because Axios is a trusted package and standard installation workflows were used, this activity may be difficult to detect. Organizations should promptly identify affected systems, remediate compromised environments, and strengthen dependency controls to reduce future risk.

Serious Risk

Trusted software supply chain attacks are a stark reminder that we’re only as strong as our weakest link. Supply chain attacks are lucrative to attackers as they offer mass distribution vectors, inherited and often escalated trust, persistence through normal operations, and delayed detection. This can be a serious headache for organizations and greatly increase the risk of continuous exploitation.

Axios is a widely used JavaScript library that enables applications to send HTTP and HTTPS requests to servers, making it easy to retrieve, send, and manipulate data from APIs. It’s pretty much everywhere… front-end applications, back-end services, build systems/scripts and automations. Because Axios is used across both client-side and server-side environments including build and deployment pipelines a compromise can impact everything from developer workstations to production systems.

This exploit chain can result in unauthorized remote access to production environments and internal systems, increasing the risk of credential compromise, sensitive data exposure, and data exfiltration. Such outcomes pose significant risk to organizations and can impact trust with clients and customers.

Attack Chain and Next Steps

The following is a high-level outline of the known attack chain and recommended next steps, synthesized from Microsoft technical research:

• Initial Access: Trusted maintainer account compromised through social engineering
• Publish: Compromised packages published to NPM through trusted account
• Install: Malicious Axios version is installed (1.14.1 or 0.30.4)
• Dependency Execution: Embedded dependency drops a stage-one loader (setup.js)
• C2 Communication: Second-stage loader connects to attacker-controlled infrastructure
• Payload Delivery: OS-specific second-stage payload (RAT) is downloaded and executed
• RAT Activity: Establishes remote access, executes commands, and maintains persistence.

Organizations should treat ANY affected system as fully compromised and prioritize both immediate remediation and longer-term supply chain controls.

High Priority

• Identify use of impacted Axios versions (1.14.1, 0.30.4)
• Roll back to a known safe version (1.14.0, 0.30.3, or earlier)
• Remove node_modules and reinstall dependencies from a trusted state
• Clear local NPM cache to prevent reinstallation of malicious artifacts
• Rotate credentials exposed on affected systems (API keys, tokens, environment variables)

Near-Term

• Hunt for indicators of compromise:
  • Presence of:
    • plain-crypto-js
    • [email protected]
    • [email protected]
  • Network traffic to:
    • sfrclak.com
    • 142.11.206.73:8000

• Review CI/CD logs and build artifacts for:
  • Installation of impacted versions
  • npm install / npm ci execution logs

• Validate no persistence mechanisms remain on affected systems

Strategic

• Enforce dependency version pinning
  • Prevent unintended upgrades to compromised versions and reduce reliance on implicit “latest version” updates
• Restrict or monitor install-time scripts
  • Reduce the risk of malicious code execution during dependency installation
• Improve supply chain visibility
  • Leverage Software Bill of Materials (SBOM)s and dependency monitoring tools to track third-party risk (CISA, n.d.)
• Limit automated dependency updates
  • Require validation and approval before introducing new package versions

In Supply Chains We Trust – Until We Can’t

Trust in upstream software no longer guarantees integrity. As organizations accelerate development through automation, AI, and rapid deployment practices, attackers are increasingly exploiting these trusted processes to distribute malicious code at scale. The Axios incident underscores a broader reality: compromise doesn’t require exposed services or unpatched systems; only a breakdown in trust within the supply chain.

Attackers continue to rapidly evolve and adopt new tools, techniques, and procedures. To keep pace, organizations must adopt a security model rooted in verification and visibility, combining preventive controls with strong detection capabilities. Secure dependency management must be treated as a baseline requirement, not an optional best practice.