TL;DR

In late March 2026, two of the most widely-used npm packages—Trivy (34K GitHub stars) and Axios (109K GitHub stars)—were compromised within days of each other. Both attacks exploited the same fundamental vulnerability: npm’s trust-based security model that assumes maintainers with valid credentials are legitimate publishers. The incidents affected millions of developers and exposed systemic weaknesses that PyPI addressed years ago with cryptographic attestations.

Executive Summary

Between March 19 and March 31, 2026, the npm ecosystem suffered two independent but structurally identical supply chain attacks targeting security-critical packages. Trivy, an open-source vulnerability scanner used in CI/CD pipelines worldwide, was compromised through credential theft. Axios, one of the most popular HTTP clients in the JavaScript ecosystem with approximately 40 million weekly downloads, was attacked via a social engineering campaign that installed a Remote Access Trojan (RAT) on the lead maintainer’s computer.

Both attacks delivered malicious code to downstream users within hours of publication. Both exploited the same weakness: npm accepts any package version signed with valid maintainer credentials, regardless of whether those credentials were obtained through theft, social engineering, or malware. The ecosystem offers no cryptographic verification that a published package actually came from its stated maintainer.

This analysis examines the attack timelines, root causes, and broader implications for the JavaScript ecosystem. The key finding: npm’s security model lags behind Python’s PyPI by at least two years. PyPI implemented PEP 740 attestations using Sigstore for cryptographic package verification in 2024. npm has no equivalent mechanism.

Key Data Points:

Metric	Trivy Attack	Axios Attack
GitHub Stars	34,331	109,015
Exposure Window	3-12 hours	~3 hours
Attack Vector	Credential theft	Social engineering + RAT
Malicious Versions	v0.69.4 + 76 tags pushed	1.14.1, 0.30.4
Weekly Downloads	High (CI/CD)	~40M

Background & Context

The npm ecosystem has experienced supply chain attacks for years, but the March 2026 incidents represent a troubling escalation in both sophistication and impact. To understand why these attacks succeeded and what they reveal about systemic vulnerabilities, we must examine the history of npm security and the trust model that underpins it.

Historical Pattern of npm Supply Chain Attacks

The JavaScript ecosystem has seen a series of high-profile supply chain incidents that established a clear pattern:

• event-stream (2018): A popular package was transferred to an unknown developer who added malicious code targeting cryptocurrency wallets. The maintainer had grown tired of maintaining the project and handed it off without vetting.

• colors.js/faker.js (January 2022): Developer Marak Squires deliberately corrupted his own packages in protest of unpaid open-source maintenance work. Millions of applications broke when the packages started printing infinite loops of garbage characters.

• ua-parser-js (October 2021): The package was compromised through maintainer account access, distributing cryptocurrency-mining malware.

Each incident exposed different vulnerabilities in npm’s trust model, yet the registry’s fundamental approach remained unchanged: trust the maintainer, verify only the credentials.

npm’s Current Security Model

The npm registry operates on three core assumptions:

1. Maintainers are trustworthy actors who will not intentionally publish malicious code
2. Valid npm credentials prove maintainer identity and authorization
3. Version tags are reliable pointers to specific code states

All three assumptions failed in the March 2026 attacks:

• Trivy proved that credentials can be stolen from well-resourced, security-conscious organizations
• Axios demonstrated that maintainers can be socially engineered, with attackers spending weeks building trust before striking
• Both incidents showed that npm’s publishing model allows rapid tag manipulation before detection

The registry’s response mechanisms—unpublishing within 72 hours and security advisories—are reactive, not preventive. Neither attack was detected by npm’s own monitoring systems; both were identified by community members and third-party security researchers.

PyPI’s Contrasting Approach

Python’s package registry took a fundamentally different path after experiencing its own supply chain incidents. In 2024, PyPI implemented PEP 740 attestations using Sigstore, a system for cryptographic signing and verification of software artifacts.

Under this model:

• Package publishers cryptographically sign releases using their GitHub identity via OpenID Connect (OIDC)
• The signature becomes part of the package metadata in a verifiable “bundle”
• Consumers can verify that a package was actually published by its stated maintainer
• The attestation is stored in a public transparency log, creating an immutable record

PyPI’s implementation means that even if an attacker steals a maintainer’s PyPI credentials, they cannot publish a validly-signed package without also compromising the maintainer’s GitHub account and OIDC flow. This represents a significant barrier compared to npm’s credential-only model.

Analysis Dimension 1: Attack Vectors and Methodology

The Trivy and Axios attacks, while targeting different packages with different technical payloads, shared an identical root cause: compromised maintainer credentials. Understanding the specific attack methodologies reveals how current security practices fail to prevent sophisticated attacks.

Trivy Attack: Credential Theft and Multi-Vector Distribution

Timeline:

Date/Time (UTC)	Event	Significance
Mar 19, 17:43	Malicious v0.69.4 tag pushed	Attack begins
Mar 19, 18:22	v0.69.4 release artifacts public	Malicious binaries distributed via GitHub, Deb, RPM, containers
Mar 19, 21:42	v0.69.4 removed	~3 hour exposure for binary releases
Mar 20, 05:40	trivy-action tags restored	~12 hour exposure for GitHub Actions
Mar 22, 15:43	DockerHub images compromised	Second wave attack
Mar 23, 01:40	DockerHub images removed	~10 hour container exposure
Mar 24, 17:53	GHSA-69fq-xp46-6x23 published	Official advisory

The attack demonstrated sophisticated understanding of Trivy’s distribution channels. Rather than compromising a single release point, the attacker:

1. Published a malicious binary release (v0.69.4) through GitHub releases
2. Force-pushed 76 out of 77 version tags in the trivy-action GitHub Actions repository, affecting CI/CD pipelines globally
3. Replaced 7 tags in the setup-trivy action
4. Compromised DockerHub images (v0.69.5 and v0.69.6) in a second wave

The multi-vector approach maximized blast radius: developers pulling the binary, CI pipelines using the Actions, and container-based deployments all faced exposure.

Attack Vector Analysis:

The GitHub Security Advisory GHSA-69fq-xp46-6x23 indicates compromised credentials were used to publish the malicious version. The advisory does not specify how credentials were obtained, but the attack pattern suggests:

• Targeted credential harvesting from a maintainer or infrastructure
• Knowledge of Trivy’s multi-channel distribution (releases, Actions, DockerHub)
• Rapid publication across all channels before detection

Ironically, Trivy is a vulnerability scanner—the tool designed to detect security issues became the vector for distributing them.

Axios Attack: Social Engineering Campaign

Timeline:

Date/Time (UTC)	Event	Significance
Mar ~17-30	Social engineering campaign	Attacker builds relationship with maintainer
Mar ~30	RAT installed on maintainer PC	Device compromised
Mar 31, 00:21	Malicious versions published	[email protected] and 0.30.4 pushed
Mar 31, 03:00	Issue #10604 opened	Community detects compromise
Mar 31, 03:15	Malicious versions removed	~3 hour exposure
Apr 02, 15:06	Post mortem published	Full disclosure

The Axios attack was more personal and more patient. According to the official post mortem by maintainer Jason Saayman:

“The attacker gained access to the lead maintainer’s PC through a targeted social engineering campaign and RAT malware.”

Attack Vector Analysis:

• Duration: Approximately two weeks of relationship-building before the attack
• Method: Social engineering culminating in installation of a Remote Access Trojan
• Payload: Malicious dependency [email protected] that installed a cross-platform RAT
• C2 Servers: Identified as sfrclak[.]com and 142.11.206.73:8000

The attack demonstrates that even maintainers of security-conscious packages can be personally targeted. The Axios maintainer took full accountability:

“I want to be completely transparent about what happened… The attacker gained access to the lead maintainer’s PC through a targeted social engineering campaign and RAT malware.”

After detection, the maintainer:

1. Wiped all devices
2. Reset all credentials
3. Began implementing immutable releases
4. Started transitioning to OIDC publishing
5. Published a detailed post mortem for community learning

Common Attack Pattern

Both attacks followed an identical high-level pattern:

Credential Compromise -> Malicious Version Publication -> Distribution via Trust -> Detection (External) -> Removal

Neither attack was detected by npm’s internal systems. Both were identified by:

• Trivy: Internal monitoring by Aqua Security
• Axios: Community member reporting suspicious behavior (Issue #10604)

This pattern reveals a critical gap: npm’s security model detects attacks only after malicious code has been distributed to users.

Analysis Dimension 2: Ecosystem Vulnerability Assessment

The npm ecosystem’s vulnerability to supply chain attacks stems from structural characteristics that differ significantly from other package registries. Understanding these differences reveals both the scope of the problem and potential solutions.

The Trust Assumption Problem

npm’s security model is built on a fundamental trust assumption: maintainers with valid credentials are legitimate publishers. This model works adequately when:

• Maintainers are careful with credentials
• Attackers don’t target maintainers directly
• Compromised credentials are detected quickly

The March 2026 attacks broke all three assumptions:

1. Trivy: Even a security-focused organization (Aqua Security) couldn’t prevent credential theft
2. Axios: A sophisticated social engineering campaign directly targeted the maintainer
3. Both: Detection relied on external parties, not internal monitoring

The table below compares npm’s security model to other package registries:

Security Feature	npm	PyPI	Cargo	Maven
Cryptographic Signing	No	Yes (PEP 740/Sigstore)	Planned	Optional GPG
Immutable Releases	No (72h unpublish window)	Yes	Strict	Yes
OIDC Publishing	Optional	Yes (Sigstore)	Planned	No
Attestation Verification	No	Yes	In development	No
Built-in Malware Scanning	Limited	Yes	Limited	No

Single Points of Failure

A significant but often overlooked vulnerability is the maintainer concentration problem. While the exact percentage of npm packages with single-maintainer dependencies is not publicly documented, the pattern is clear from historical incidents:

• colors.js/faker.js: One maintainer (Marak) controlled packages affecting millions of projects
• event-stream: A single maintainer transferred ownership to an attacker
• Axios: Multiple maintainers, but the lead maintainer’s account was the compromise point

Even multi-maintainer packages are vulnerable if the primary maintainer’s credentials are compromised. The Axios case demonstrates that having multiple maintainers doesn’t prevent targeted attacks on the most privileged account.

Blast Radius Analysis

The potential impact of supply chain attacks scales with package popularity:

“Axios weekly downloads: ~40M (extrapolated from 109K GitHub stars and npm popularity)”

Source: npm registry popularity analysis

A 3-hour exposure window with 40 million weekly downloads means approximately 70,000 downloads could have pulled the malicious version in that short window. Even a 1% infection rate would impact 700 projects.

For Trivy, the blast radius is harder to quantify but potentially more severe in enterprise environments:

• 34,331 GitHub stars indicate broad adoption
• Integration into CI/CD pipelines means automated runs at scale
• Compromised security scanners could mask vulnerabilities rather than detect them

The Socket.dev blast radius analysis notes that downstream dependencies amplify the impact:

“The hidden blast radius extends beyond direct Axios users to all packages that depend on Axios transitively.”

Historical Precedent Pattern

The attacks fit a documented pattern of npm supply chain compromises:

Incident	Year	Attack Vector	Exposure
event-stream	2018	Maintainer transfer	Days
ua-parser-js	2021	Credential compromise	Hours
colors.js/faker.js	2022	Intentional sabotage	Hours
Trivy	2026	Credential theft	3-12 hours
Axios	2026	Social engineering + RAT	3 hours

The pattern shows:

1. Attacks are accelerating (two major incidents in one week)
2. Attack sophistication is increasing (targeted social engineering)
3. Detection remains reactive (community/third-party, not registry)

Analysis Dimension 3: Comparative Ecosystem Security

The npm ecosystem is not alone in facing supply chain attacks, but its response has been slower than other package registries. PyPI’s implementation of cryptographic attestations provides a concrete model for what npm could adopt.

PyPI’s PEP 740 Attestations

In 2024, the Python Package Index implemented PEP 740, which enables:

1. Sigstore-based signing: Publishers sign packages using their GitHub identity via OIDC
2. Transparency logs: Signatures are stored in a public, immutable log
3. Verification bundles: Consumers can verify package authenticity independently
4. pypi-inspector tool: Allows browsing package files before installation

The Sigstore Python client (315 GitHub stars) provides the tooling for this verification:

# Example verification flow (conceptual)
from sigstore_python import verify

# Verify package attestation
result = verify(package="requests", version="2.31.0")
if result.valid:
    print(f"Package verified: signed by {result.signer}")
else:
    print("Warning: Package attestation verification failed")

This means that even if an attacker steals a PyPI maintainer’s password, they cannot publish a package with a valid attestation without also compromising:

1. The maintainer’s GitHub account
2. The OIDC flow between GitHub and PyPI
3. The transparency log (computationally infeasible)

npm’s Current Gap

npm has no equivalent to PEP 740. The registry relies on:

• Optional 2FA: Maintainers can enable two-factor authentication, but it’s not required
• Token-based publishing: npm tokens can be generated and used for CI/CD
• Unpublish window: Packages can be unpublished within 72 hours

The gap is significant because npm tokens are “bearer tokens”—anyone with the token can publish. If a token is stolen (as in the Trivy attack), the attacker has full publishing access until the token is revoked.

Sigstore Ecosystem Adoption

Sigstore has gained significant adoption for supply chain security:

Tool	Purpose	GitHub Stars
cosign	Container/binary signing	5,781
gitsign	Git commit signing	1,076
sigstore-python	PyPI attestations	315
OpenSSF Scorecard	Security scoring	5,351

The infrastructure exists for npm to adopt similar verification. The question is why the JavaScript ecosystem has been slower to implement it.

Enterprise Tool Adoption

In the absence of npm-native solutions, enterprises have turned to third-party tools:

• Socket.dev: npm security scanner with supply chain attack detection
• Snyk: Dependency scanning with vulnerability alerts
• StepSecurity: GitHub Actions hardening and OIDC workflows
• Renovate (21,199 stars): Automated dependency updates with pinning
• Dependabot (5,514 stars): GitHub’s built-in dependency updates

These tools provide defense-in-depth but require active adoption. They do not address the fundamental gap: npm lacks built-in verification that a package was published by its stated maintainer.

Key Data Points

Metric	Value	Source	Date
Trivy GitHub Stars	34,331	GitHub API	2026-04-04
Axios GitHub Stars	109,015	GitHub API	2026-04-04
Axios Weekly Downloads	~40M	npm extrapolation	2026-03
Trivy v0.69.4 Exposure	~3 hours	GHSA-69fq-xp46-6x23	2026-03-19
trivy-action Exposure	~12 hours	GHSA-69fq-xp46-6x23	2026-03-19-20
Trivy DockerHub Exposure	~10 hours	GHSA-69fq-xp46-6x23	2026-03-22-23
Axios Exposure Window	~3 hours	axios/issues/10636	2026-03-31
OpenSSF Scorecard Stars	5,351	GitHub API	2026-04-04
Cosign Stars	5,781	GitHub API	2026-04-04
Renovate Stars	21,199	GitHub API	2026-04-04
PyPI Warehouse Stars	3,993	GitHub API	2026-04-04
npm CLI Stars	9,648	GitHub API	2026-04-04

🔺 Scout Intel: What Others Missed

Confidence: high | Novelty Score: 85/100

Media coverage of the Trivy and Axios attacks treated them as separate incidents—“another npm supply chain attack” headlines focused on the immediate impact and remediation steps. What the coverage missed is the structural pattern: both attacks exploited the exact same vulnerability, and npm has no roadmap to fix it.

The Axios maintainer’s response—implementing OIDC publishing and immutable releases—is exactly what npm should mandate ecosystem-wide. Instead, individual maintainers are left to implement their own security postures. The StepSecurity analysis notes that OIDC for publishing is an “emerging best practice” but not a registry requirement.

PyPI’s PEP 740 implementation, now over a year old, demonstrates that cryptographic verification is technically feasible at registry scale. The Sigstore Python client handles the complexity transparently. npm’s continued reliance on bearer tokens and trust-based publishing represents a willful security gap.

The deeper issue is maintainer sustainability. Both attacks targeted unpaid volunteers. The Axios social engineering campaign operated for approximately two weeks before striking—time investment that suggests professional threat actors. Open source maintainers are defending against nation-state-level adversaries with no security budget, no formal training, and no institutional support.

Key Implication: Organizations relying on npm should implement private registry proxies and dependency pinning immediately, as npm has demonstrated no timeline for implementing cryptographic verification that would prevent these credential-based attacks.

Outlook & Predictions

Near-term (0-6 months)

Prediction: npm will announce a roadmap for Sigstore integration or similar cryptographic verification mechanism. Confidence: Medium.

The pressure from two high-profile attacks in one week, combined with the PyPI precedent, creates significant community demand. However, npm has historically moved slowly on security changes due to ecosystem size and backward compatibility concerns.

Key trigger to watch: Official npm blog post or RFC announcing Sigstore integration or attestation pilot program.

Immediate developer actions:

Action	Priority	Tool/Method
Pin dependencies to specific versions	Critical	package-lock.json, yarn.lock
Check lockfiles for affected versions	Critical	grep -E 'axios@(1.14.1|0.30.4)|plain-crypto-js'
Rotate all secrets if exposed	Critical	Treat machine as compromised
Enable immutable releases	High	GitHub repository settings
Implement private registry	High	Verdaccio, npm Enterprise
Adopt dependency scanning	Medium	Socket.dev, Snyk

Medium-term (6-18 months)

Prediction: At least one more major npm supply chain attack before ecosystem-wide cryptographic verification is implemented. Confidence: High.

The attack vectors remain open. Social engineering campaigns targeting maintainers are low-cost, high-reward for attackers. The Axios attack demonstrated that maintainers of popular packages are soft targets.

Prediction: Enterprise adoption of private npm registries and proxy layers will increase significantly. Confidence: High.

The Socket.dev analyses and Snyk advisories demonstrate the market demand for third-party security layers when the registry itself doesn’t provide verification.

Long-term (18+ months)

Prediction: npm will implement cryptographic attestation verification, but adoption will be slow due to the ecosystem’s size and backward compatibility requirements. Confidence: Medium.

PyPI’s experience provides a template, but npm’s ecosystem is larger and more fragmented. The JavaScript community will need tooling updates, CI/CD workflow changes, and maintainer education to reach meaningful adoption.

Prediction: Regulatory requirements will mandate software supply chain verification for critical infrastructure, driving adoption regardless of npm’s timeline. Confidence: Medium.

The U.S. Executive Order on Improving the Nation’s Cybersecurity (2021) and subsequent NIST guidance on software supply chain security create regulatory pressure. Organizations subject to these requirements will need verifiable supply chains—npm’s current model won’t suffice.

Key Trigger to Watch

The most significant indicator of ecosystem change would be an official npm announcement about Sigstore integration or attestation support. Without such a roadmap, the ecosystem remains vulnerable to the exact attack vector that compromised Trivy and Axios.

Until then, the pattern is clear: maintainer credentials are the soft underbelly of the npm ecosystem, and attackers have learned exactly where to strike.

Sources

• GitHub Security Advisory GHSA-69fq-xp46-6x23 — Trivy Supply Chain Attack Advisory, March 2026
• Axios Post Mortem Issue #10636 — Official Axios Incident Analysis, April 2026
• InfoQ - Trivy Supply Chain Attack — Technical News Coverage, April 2026
• InfoQ - Axios npm Supply Chain Attack — Technical News Coverage, April 2026
• StepSecurity - Axios Technical Analysis — Full Technical Analysis and Remediation, April 2026
• Socket.dev - Axios Social Engineering Analysis — Attack Vector Deep Dive, April 2026
• Socket.dev - Axios Blast Radius Analysis — Downstream Impact Analysis, April 2026
• Snyk - Axios Advisory — Security Advisory and Scanning Guidance, April 2026
• OpenSSF Scorecard — Security Health Metrics for Open Source
• Sigstore Cosign — Container Signing and Verification
• Sigstore Gitsign — Keyless Git Commit Signing
• PyPI Warehouse — Python Package Index with PEP 740 Attestations