npm ci verifies downloads against the SHA-512 integrity hash stored in the lockfile

Follow the bytes on an npm install. The client fetches a metadata document for each package, picks a version that satisfies the range, then fetches the tarball for that version. The integrity field in package-lock.json is a SHA-512 of the tarball npm expects to install ^[11]. That value only exists for versions already written into the lockfile, and it was recorded from whatever the registry served the first time the dependency resolved.

Which layer got poisoned decides whether the hash helps. The dev.to post describes a cache-key collision that could return one package's metadata, and in some edge cases gem contents, for a request meant for a different package or version ^[4]. Substitute a tarball and npm ci throws an integrity error ^[13]. Substitute the metadata document and the damage lands at resolution, before a hash for that artifact exists: adding a new dependency, or letting plain npm install move a package to a newer in-range version, which the post calls silent resolution drift ^[14].

For the RubyGems finding to transfer, npm's cache key would have to collide the same way. The post's argument is structural. registry.npmjs.org sits behind Cloudflare, and npm, PyPI and crates.io all run comparable caching layers ^[10][9]. It says "cache-key logic bugs are a class of vulnerability, not a one-off Ruby mistake" ^[20]. A transfer takes two things: npm's key normalising away something that distinguishes two requests, and a client reading the poisoned object without a pinned hash to check it against. The post shows neither for npm.

Provenance is the other control on offer. npm audit signatures, available since npm 9.5, verifies package provenance signatures against the registry ^[15]. It defeats a cache substitution only if the signing happens upstream of the cache and the client checks the signature on the copy it actually installed. The post lists it as a command to run alongside npm audit --audit-level=high ^[15].

The chain of evidence is one dev.to post, originally published at adityarawas.in, which attributes the discovery of mismatched gemspecs to Tenderlove's writeup ^[18][6]. The supplied text is undated and cites no CVE or RubyGems advisory ^[19]. It reports that nothing indicated malicious exploitation before discovery ^[7], and that an attacker who understood the cache-key logic could have engineered collisions so a popular gem name resolved to attacker-controlled code for some subset of installs ^[8].

The npm remediation holds even if that account is incomplete. npm ci fails on a hash mismatch whether or not a CDN ever collided a key ^[13]. The cost is procedural: npm ci refuses to modify the lockfile ^[13], so the pipeline needs a committed lockfile that already matches package.json, and every dependency bump becomes an explicit local step. In my view that is worth paying in CI. In this threat model, cache poisoning is the one attack class that works without a compromised maintainer account or a published malicious package ^[16][17].