TL;DR: PackageGate exposed six zero-day flaws across npm, pnpm, vlt, and Bun, but npm declined to patch the bypass that lets attackers evade --ignore-scripts through git dependency .npmrc injection, per Pixee’s analysis. The issue turns package-manager choice into a security governance decision, because known weaknesses now map directly to audit burden, supply-chain resilience, and remediation capacity.
Editorial analysis by NHI Mgmt Group, based on content published by Pixee: “Six Zero-Days, One Refusal: How npm Created Two-Tier JavaScript Security”.
Key questions
Q: What breaks when a package manager leaves a documented bypass unpatched?
A: The control assumption breaks, not just the tool.
Q: Why do git dependencies create supply-chain risk that registry scanning misses?
A: Because the dangerous content can live outside the registry and enter the build during dependency resolution, not package publication.
Q: How should teams govern package-manager choice in CI/CD pipelines?
A: Treat package-manager choice as part of the security architecture, not just developer ergonomics.
Practitioner guidance
- Audit git dependency paths for installer-side bypasses Identify repositories and build pipelines that pull dependencies from git URLs, then test whether install-time controls such as --ignore-scripts are actually enforced in those paths.
- Separate registry scanning from source provenance checks Add controls that inspect dependency source locations, commit references, and repository content so malicious behavior hidden outside package metadata is still evaluated.
- Reclassify package-manager selection as a security decision Document which package managers in your estate patch known install-path flaws and which may leave documented behavior unpatched, then route high-risk projects accordingly.
Bottom line: PackageGate shows that package-manager policy can be as important as package content when install-time controls are bypassable.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Package-manager policy is now part of supply-chain security posture. The article shows that the same class of weakness can be treated as a patchable flaw in one ecosystem and as expected behavior in another. That changes the governance burden for engineering leaders because the tool choice now determines where accountability sits when a control fails. Practitioners should treat package-manager selection as a security control decision, not a build preference.
A few things that frame the scale:
- CrowdStrike's 2026 Global Threat Report said zero-days exploited before public disclosure rose 42% year over year.
A question worth separating out:
Q: When should organisations move beyond dependency metadata checks?
A: When they rely on git dependencies, script-disabling settings, or other install-time safeguards that can be bypassed through source-controlled content. Metadata checks are still useful, but they are not enough when the attacker path is resolved during installation rather than publication. At that point, provenance, install behavior, and execution controls all need to be part of the review.
👉 Read our full editorial: PackageGate exposes the security cost of unpatched npm behavior