SSRF via unvalidated .npmrc registry URL in npm dependency resolution

[Ryujiyasu]

Summary

osv-scanner reads the registry= value from a project's .npmrc file and uses it as the base URL for all npm package metadata HTTP requests, with no scheme or host validation.

Vulnerable Code

The vulnerable code is in internal/datasource/npmrc.go (line 247), where registry=<value> is stored directly into config.ScopeURLs[""] without validation, and subsequently used as the base URL for all npm HTTP requests via http.DefaultClient (internal/datasource/npm_registry.go:91).

Attack Scenario

An attacker who controls a scanned repository can set registry=http://169.254.169.254/ in the .npmrc to direct the scanner to make HTTP requests to internal addresses.

Additionally, if the .npmrc contains authentication credentials (_authToken, _auth, username/password) scoped to the attacker-controlled registry URL, those credentials are attached to the outgoing requests, enabling credential exfiltration.

This is triggered by osv-scanner fix <package-lock.json> against any npm project containing a malicious .npmrc.

This affects all CI/CD systems running osv-scanner fix on npm projects: GitHub Actions, Google Cloud Build, Jenkins on GCE/EC2, and any developer running osv-scanner fix locally on untrusted code.

Suggested Fix

Validate the registry URL in npmrc.go before storing it: reject private IP ranges, loopback addresses, and link-local addresses (169.254.x.x).

[cuixq]

I transferred this issue from osv-scanner since we are migrating all our native data source clients to scalibr. I have also assigned this issue to @michaelkedar who is able to better answer this question.