Six Vulnerabilities in Major JavaScript Package Managers Expose Projects to Supply-Chain RCE

A security research team has uncovered a cluster of implementation weaknesses across four leading JavaScript package managers that collectively weaken widely relied-upon defenses against dependency-based attacks. The findings show attackers can evade mechanisms intended to stop automatic script execution during installs and undermine integrity checks that validate packages after the initial install. Each package manager has a distinct failure mode: one allows crafted configuration in a Git-sourced dependency to trigger execution, another treats Git-sourced modules differently from built packages and thus skips script restrictions, a third performs tarball extraction in a way that permits path-walking and arbitrary file writes, and a fourth enforces a script allowlist by package name without validating the origin, enabling spoofing. The researchers also found that some managers store only the download URL for tarball dependencies rather than recording cryptographic hashes, which means a tarball that was safe at first install can be swapped out later and deliver malicious payloads on subsequent installations. That combination—differential handling of Git/tarball sources plus missing integrity metadata—gives an attacker multiple practical routes to escalate from a malicious dependency to targeted remote code execution in downstream projects. The vendor responses were mixed: three projects moved to patch the logic within weeks, while the maintainer of the most widely used manager declined to change behavior, characterizing the reported behavior as intentional. The researchers caution that proof-of-concept techniques are circulating, increasing the likelihood that opportunistic actors will weaponize the gaps. For development teams, the vulnerabilities highlight blind spots in common best practices: lockfiles and script-disabling flags are only effective when the package manager’s dependency-resolution and metadata storage model fully covers Git and tarball sources. Operational mitigations include avoiding or tightly controlling Git- and tarball-based dependencies, insisting on recorded integrity hashes for every source, and adding network or provenance controls that detect or block unexpected registry or tarball changes. The incident underscores the systemic nature of supply-chain risk in open source ecosystems where subtle differences in implementation create exploitable seams. Left unaddressed across the board, these flaws allow attackers to target installations based on environment, timing, or network origin, turning a single compromised package into a precise attack against chosen victims.