The Not-So-Hidden Pattern in Axios attack
Interlynk
What Happened?
On March 31, 2026, two new versions of axios - the most widely used HTTP client library in the JavaScript ecosystem - were published to npm by a compromised maintainer account. The malicious versions (1.14.1 and 0.30.4) reached over 100 million weekly downloads combined. They introduced a hidden dependency called plain-crypto-js, which silently deployed a cross-platform Remote Access Trojan (RAT) on every developer machine, CI/CD pipeline, and production environment that ran a routine npm install.
Both Google Threat Intelligence Group and Microsoft Threat Intelligence attributed the attack to UNC1069 / Sapphire Sleet, a North Korea-nexus, financially motivated threat actor active since at least 2018. The malicious versions were live for approximately three hours - just long enough to cause massive downstream exposure before npm took them down.
If your organization uses any Node.js software, there is a high probability that axios is somewhere in your dependency tree - even if no developer ever explicitly added it. That's the nature of transitive dependencies. And that's precisely what makes this attack so dangerous.
The Attack, Step by Step
The axios compromise followed a precise operational sequence that security researchers have now documented in full detail:
Step 1 - Credential theft. The attacker obtained a long-lived classic npm access token for the account of @jasonsaayman, the primary axios maintainer. Despite the account having MFA configured, the attacker bypassed it by using the stolen token directly - a known gap when legacy tokens co-exist with OIDC-based publishing workflows.
Step 2 - Account takeover. The registered email on the maintainer account was quietly changed from the legitimate Gmail address to a Proton Mail address (ifstap@proton.me) under the attacker's control - a common pivot to lock out the real owner.
Step 3 - Malicious package pre-staging. Before touching axios itself, the attacker published plain-crypto-js@4.2.0 as a clean decoy to build registry history and credibility, followed by plain-crypto-js@4.2.1 - the malicious payload delivery vehicle.
Step 4 - Poisoning both release branches. Within a 39-minute window, the attacker published axios@1.14.1 (tagged latest) and axios@0.30.4 (tagged legacy). Both versions had plain-crypto-js@4.2.1 injected as a dependency. Tagging both channels maximized blast radius across projects using either the current or legacy axios API.
Step 5 - Silent post-install execution. The malicious plain-crypto-js declared a post-install lifecycle hook. The moment any environment ran npm install, setup.js executed automatically - no user interaction required. Within two seconds of install, the malware was already calling home to the attacker's C2 server at sfrclak[.]com:8000 at IP (142.11.206[.]73)
Step 6 - Platform-specific RAT deployment. The dropper detected the host operating system and deployed a tailored second-stage payload - a cross-platform RAT called WAVESHAPER.V2 - for macOS, Windows, and Linux. The RAT immediately began system reconnaissance, enumerating directories, running processes, and exfiltrating credentials, SSH keys, cloud tokens, and API secrets.
Step 7 - Provenance gap as camouflage. Legitimate axios releases always include OIDC provenance metadata and SLSA build attestations linking the npm package back to a specific GitHub Actions run. The malicious versions had none. Defenders who had provenance-checking in place caught this immediately; those relying on traditional vulnerability scanners saw nothing - because plain-crypto-js had no CVE.
Emerging Attack Pattern
The axios attack is the latest data point in a long-running and accelerating trend.
Every step of this playbook has been executed before - often by the same class of threat actors, against similarly critical open-source packages:
event-stream (2018): A malicious contributor gained publishing rights to a dormant npm package with 2 million weekly downloads and injected a backdoor targeting a specific Bitcoin wallet. The attack remained undetected for weeks.
SolarWinds Orion (2020): Nation-state actors (Nobelium/APT29) compromised the SolarWinds build pipeline and inserted the SUNBURST backdoor into signed software updates distributed to 18,000 organizations, including U.S. federal agencies. The attack went undetected for 14 months.
ua-parser-js (2021): A hijacked npm account was used to publish malicious versions of a library with 8 million weekly downloads, deploying cryptominers and credential stealers - the same account-takeover vector used against axios five years later.
XZ Utils (2022–2024): A sophisticated threat actor spent nearly two years earning maintainer trust on a core Linux compression library before inserting a backdoor targeting OpenSSH authentication across Fedora, Ubuntu, and Debian. Caught almost by accident by a Microsoft engineer noticing SSH latency anomalies.
tj-actions/changed-files (2025): A GitHub Action used in thousands of CI/CD workflows was compromised via tag poisoning, exfiltrating secrets from runner environments at scale.
Trivy / TeamPCP (2026): Days before the axios attack, threat actor TeamPCP stole an access token from the Trivy security scanner's GitHub Actions workflow, poisoned 76 version tags overnight, harvested credentials from CI/CD environments, and used stolen npm tokens to self-propagate a worm (CanisterWorm) across 66+ npm packages - all within days of the axios attack.
The common thread across all of these attacks: compromise a trusted component, ride the implicit trust of the ecosystem, and reach every downstream user automatically. The axios attack didn't invent this - it perfected it at scale.
The Acceleration Is Real
Supply chain attacks used to be surgical, patient operations measured in months or years. The XZ Utils backdoor took two years of social engineering. SolarWinds went undetected for 14 months. Today, the axios attack was identified within 6 minutes of publication by behavioral analysis tools - and still hit 135+ endpoints before containment. The timeline has compressed from years to hours. AI is now being used by attackers to generate malicious packages, automate propagation, and find weaknesses at machine speed, while AI coding agents on the developer side are selecting known-vulnerable dependency versions at rates 50% higher than humans. The attack surface is growing faster than the defense.
Mitigation Best Practices
No single control stops every supply chain attack. Effective defense requires multiple independent layers operating across the full SDLC:
Know What You're Running - Always
You cannot detect or respond to a supply chain attack on a component you didn't know you were using. Automated SBOM generation embedded throughout the SDLC - not as a one-time audit deliverable, but as a continuous record of exactly what is in every build -is the foundational control. An SBOM produced at build time captures transitive dependencies like plain-crypto-js before they ever reach production.
Pin Dependencies. Commit Lockfiles.
Floating version ranges (^1.14.0, ~1.14.0) are an open invitation for supply chain attacks. Any update that falls within the range installs automatically. Pin to exact versions. Commit your package-lock.json. Use npm ci (not npm install) in all CI/CD pipelines - it respects the lockfile exactly and will not silently upgrade to a malicious patch release.Enforce Provenance and Build Attestation
Require OIDC provenance metadata and SLSA Level 2+ for all critical third-party packages. The axios attack's clearest early signal was the absence of provenance on new versions of a package that had always included it. Absence of provenance on a new version of a major package should trigger an automatic alert - not just a manual investigation after the fact.Apply a Publication Cooldown Policy
Implement a minimum release age policy - blocking installation of packages published within the last 72 hours. This gives the security community time to analyze new releases before they enter your supply chain. The axios malicious versions were live for only three hours; a 72-hour cooldown would have blocked them entirely for the vast majority of organizations.Disable or Audit Postinstall Scripts
The entire axios attack chain hinged on npm's postinstall lifecycle hook. Most production builds don't need lifecycle scripts from third-party packages. Use npm install --ignore-scripts in CI/CD pipelines where scripts are not required. When scripts are necessary, audit and allowlist them explicitly.Monitor for Anomalous Behavior at Runtime
Traditional vulnerability scanners look for known CVEs. Supply chain attacks like axios introduce entirely new packages with no CVE history. Behavioral monitoring - watching for unexpected outbound network connections from build environments, new processes spawned by npm install, or anomalous credential access patterns - catches what signature-based tools miss. Within two seconds of install, the axios RAT was already calling home. Network egress monitoring from CI runners would have detected it immediately.Rotate Credentials Aggressively and Revoke Long-Lived Tokens
The axios attack was possible because a long-lived npm access token provided direct publishing access - bypassing every OIDC-based publishing control that had been put in place. Eliminate long-lived tokens wherever possible. Adopt Trusted Publishing with OIDC. Rotate all CI/CD secrets on a regular schedule, and immediately after any supply chain incident, treat every credential that touched an affected environment as compromised.
Interlynk Customer Experience with Axios
When the axios attack became public, security teams worldwide went into emergency response mode: auditing dependency trees, searching through CI/CD logs, rotating credentials, trying to answer the most basic question - are we affected?
For 77% of Interlynk customers, that question had an immediate answer. The best practices described above are not aspirational recommendations on an Interlynk checklist - they are operationalized controls built into the platform:
Continuous SBOM generation embedded across the SDLC means customers already had an up-to-date, accurate record of every dependency in every build - including transitive dependencies like plain-crypto-js.
Open source risk monitoring flagged axios version changes and new dependency introductions in real time, against continuously updated threat intelligence.
Policy enforcement across the SDLC - including dependency pinning requirements and component allowlisting - prevented the malicious versions from entering build pipelines in the first place for the majority of customers.
Supplier monitoring provided immediate visibility into which packages in the bill of materials had active security events, without requiring manual log analysis.
The 23% who were still assessing exposure had one thing in common: gaps in SBOM coverage for legacy pipelines or acquired codebases that hadn't yet been onboarded to the platform. Axios found the gap. It always does.
Real Defense: SBOM Automation Across SDLC
Organizations responding to the axios attack faced a familiar challenge: you cannot enforce what you cannot see, and you cannot see what you never tracked. Manual SBOM generation - a one-time audit document produced for a compliance deliverable - provides no protection against a supply chain attack that unfolds in three hours and starts on development machines.
The only durable answer is automating SBOM generation and policy enforcement across the full Software Development Lifecycle. Not as a point-in-time export, but as a continuous, living record of every component in every build, evaluated against up-to-date threat intelligence and organizational policy, at every stage from development through production.
This matters especially for complex organizations - those with dozens of teams, hundreds of repositories, and a mix of modern and legacy codebases. The policy question in a supply chain attack is never "are we following best practices in theory?" - it's "did every team, every pipeline, every developer workstation actually enforce the policy when it mattered?" Manual processes and team-level heroics cannot answer that question consistently at scale.
Embedding SBOM generation in the SDLC - with automated policy gates that block non-compliant components from progressing through the build pipeline, continuous monitoring for component changes against live threat intelligence, and supplier risk tracking that surfaces events like the axios compromise in real time - transforms supply chain security from a reactive incident response problem into a proactive engineering discipline.
Supply chain attacks are accelerating. The window between publication of a malicious package and first victim is now measured in seconds, not days. The only organizations that won't be scrambling to answer "are we affected?" are the ones that already know exactly what's in their software - because they automated the answer.
See how Interlynk automates SBOM across your SDLC and enforces supply chain policy at scale. Book a demo →