Six Zero-Days, One Refusal: How npm Created Two-Tier JavaScript Security

What is PackageGate? A set of six zero-day vulnerabilities disclosed in January 2026 affecting npm, pnpm, vlt, and Bun package managers. The npm-specific vulnerability allows attackers to bypass --ignore-scripts through git dependency .npmrc injection. npm declined to patch.

Six zero-day vulnerabilities. Four package managers affected. Three shipped patches within weeks. One said no.

When researchers at Koi Security disclosed PackageGate in January 2026, they documented a set of flaws affecting how npm, pnpm, vlt, and Bun handle package installations, exposing critical gaps in supply chain security. The response times told a story that had nothing to do with technical complexity:

Package ManagerResponsepnpmFixed in 2 weeksvltFixed in 8 daysBunFixed in 3 weeksnpmClosed as "works as expected"

npm's official statement to the researchers: "npm users are responsible for vetting the content of packages that they choose to install."

That's not a bug report falling through the cracks. npm made a policy statement about who bears the risk in the JavaScript ecosystem.

What PackageGate Actually Revealed

The vulnerability affecting npm allows attackers to bypass the --ignore-scripts flag through git dependency .npmrc injection. If you've configured your pipeline to disable install scripts as a security measure, that protection has a documented bypass that npm has chosen not to fix.

Koi Security put it directly: "If your organization depends on npm with --ignore-scripts as your safety net, that net has a hole in it right now."

They elaborated: "The malicious payload lives on the attacker's server, not in the npm registry, so traditional dependency scanners that rely on registry metadata completely miss it."

The other package managers treated this as a security flaw requiring a patch. pnpm addressed a script execution gap in v10 (CVE-2025-69263, CVE-2025-69264). vlt fixed a path traversal via regex flaw. Bun corrected a trust mechanism issue with 366 pre-trusted packages. Each shipped fixes and moved on.

npm's response creates a different category. The vulnerability remains. The documentation of that vulnerability is public. And the official position is that users are responsible for vetting packages they install, a standard that effectively requires every organization running npm to maintain their own security research capacity.

npm's Two-Tier Security Reality

This decision fractures the JavaScript ecosystem into two security tiers.

Teams using pnpm, yarn, vlt, or Bun operate with platform-level protections. The maintainers patch vulnerabilities when researchers find them. The security burden is shared between the platform and its users.

Teams using npm now operate differently. Known vulnerabilities may remain unpatched indefinitely if npm classifies them as expected behavior. The audit burden shifts entirely to the user. If your security model assumes your package manager is actively maintained against known attack vectors, that assumption no longer holds for npm, fundamentally altering your vulnerability management calculus.

The scale of this matters. ReversingLabs' 2026 report found a 73% increase in malicious open-source packages in 2025, with malicious activity on npm more than doubling. Of all open-source malware detected, 90% was on npm. This isn't because npm attracts bad actors. npm's market share (53-56%) makes it the highest-value target.

ReversingLabs CEO Mario Vuksan frames the stakes: "Software supply chains are no longer niche targets—they've become strategically contested attack surfaces."

npm processes 4.5 trillion package requests annually—70% year-over-year growth. That's the attack surface. And npm's position is that securing against known vulnerabilities within that surface is your responsibility, not theirs.

Separately, researchers demonstrated bypasses to npm's Shai-Hulud malware detection through git dependencies. The context: Shai-Hulud 2.0 affected 20 million weekly downloads across campaigns that compromised 1,000+ npm packages and exposed 400,000 developer secrets. Even npm's existing defenses have gaps.

The Risk Quantification

Abstract policy positions become concrete when you attach numbers. npm's two-tier reality means users now bear the full financial risk of vulnerability management—a burden quantified by growing supply chain breach costs.

Supply chain breaches cost an average of $4.91 million globally, with U.S. incidents averaging $10.22 million. Detection takes an average of 267 days. That's nine months of exposure before you know something went wrong. Overall, 30% of all data breaches now involve third-party compromise—and the projected global cost reaches $60 billion by end of year.

When npm declines to patch a known vulnerability and tells users they're responsible for vetting packages, they're describing the audit capacity they expect you to maintain. Can your team evaluate git dependencies for malicious .npmrc injection? Do you have visibility into what install scripts actually execute? Can you validate that --ignore-scripts is doing what you think it's doing?

For most organizations, the honest answer is no. Security teams are already stretched. The expectation that every enterprise maintain independent research capacity to compensate for unpatched package manager vulnerabilities isn't realistic. It's a liability transfer.

GitHub's official response to the broader supply chain challenge: "The security of the npm ecosystem is a collective effort, and we strongly encourage projects to adopt trusted publishing and granular access tokens with enforced two-factor authentication to fortify the software supply chain." Reasonable guidance—but it assumes a level of security maturity that most development teams haven't reached.

For organizations already struggling with security backlogs and alert fatigue, PackageGate adds another layer of audit burden. The math isn't theoretical—it's about capacity.

What This Means for Your Pipeline

Whether to migrate is a technical and organizational decision that depends on your codebase, your dependencies, and your team's capacity for change.

But PackageGate surfaces questions that engineering leadership should be asking:

Dependency exposure: Do you know which of your packages rely on npm-specific behaviors that wouldn't work on alternative package managers? Have you audited for git dependencies that could exploit the unpatched vulnerability?

Audit capacity: npm expects users to vet the content of packages they install. What does your vetting process actually look like? Do you have one? If npm's policy position assumes you're doing security research they've declined to do, can you actually deliver on that?

Technical debt roadmap: Package manager migration is disruptive. So is a supply chain breach. Is this conversation on your roadmap, or are you discovering it during an incident?

The market is already responding. pnpm's market share is projected to grow from 19.9% to 25-30% by year-end, driven largely by security-conscious enterprises making exactly this calculation. That's not a recommendation. It's a data point about how other organizations are weighing the same factors. Organizations managing complex dependency environments should review their SCA and dependency vulnerability strategies as part of their supply chain resilience assessment.

The Shift

Teams used to pick package managers based on speed, disk usage, and lockfile handling. Technical preferences, mostly. You chose based on workflow fit and moved on.

PackageGate changes the variable set. Security posture—specifically remediation velocity and false positive rates—is now a differentiator. The question isn't just "which package manager fits our workflow" but "which package manager accepts responsibility when vulnerabilities are found." For teams already battling security backlogs, this compounds an existing problem. Package manager choice is no longer a build tool decision—it's a vulnerability management strategy decision.

npm has answered that question clearly. The vulnerability is documented. The patch was declined. The policy is explicit.

What you do with that information is a decision your organization gets to make with full knowledge of the terms.

PackageGate disclosure details available from Koi Security. Organizations using npm should review git dependency practices and assess their package vetting capacity.