An issue in .npmrc support in Deno 1.44.0 was discovered where Deno would send .npmrc credentials for the scope to the tarball URL when the registry provided URLs for a tarball on a different domain.

Required conditions

All users relying on .npmrc are potentially affected by this vulnerability if their private registry references tarball URLs at a different domain. This includes usage of deno install subcommand, auto-install for npm: specifiers and LSP usage.

Explanation

For example, the npm registry provides information on a package at a url like this: https://registry.npmjs.org/code-block-writer -- you can see that under versions -> <version> -> dist -> tarball there's a URL (ex. https://registry.npmjs.org/code-block-writer/-/code-block-writer-1.0.0.tgz).

That URL can be anything and Deno was only considering the first URL of https://registry.npmjs.org/code-block-writer to get credentials instead of the tarball URL (so in other words, it would send the credentails for https://registry.npmjs.org/ to whatever the URL was).

You can read more about this here: https://github.com/npm/cli/wiki/%22No-auth-for-URI,-but-auth-present-for-scoped-registry%22 (how Deno is working is actually how npm used to behave)

Mitigation

It is recommended to upgrade to Deno 1.44.1 and if your private registry ever serves tarballs at a different domain to rotate your registry credentials.