`overrides` in package.json has no effect on consumers — every install still resolves `ip@2.0.1`

[clement-songis]

overrides in package.json has no effect on consumers — every install still resolves ip@2.0.1

Summary

node-av's package.json declares:

"overrides": {
  "werift":     { "@shinyoshiaki/binary-data": "npm:@seydx/binary-data@0.6.2", "ip": "npm:neoip@2.1.0" },
  "werift-dtls":{ "@shinyoshiaki/binary-data": "npm:@seydx/binary-data@0.6.2" },
  "werift-ice": { "ip": "npm:neoip@2.1.0" },
  "werift-sctp":{ "@shinyoshiaki/binary-data": "npm:@seydx/binary-data@0.6.2" }
}

These overrides are only applied when node-av's own repository is installed for
development. As soon as node-av is installed as a dependency, the field is ignored
and werift / werift-ice resolve plain ip@^2.0.1 → ip@2.0.1.

ip@2.0.1 is the last version ever published and carries an unfixed advisory,
GHSA-2p57-rm9w-gvfp / CVE-2024-29415 (SSRF via misclassification in isPublic,
CVSS 8.1). So every downstream project gets the vulnerable package and a Dependabot
alert, while the override suggests it is already handled.

This is documented behaviour rather than a bug in any package manager — npm, pnpm and
Yarn all read overrides / resolutions only from the root project's manifest, and
explicitly ignore the field in installed dependencies.

Reproduction

A single-dependency project, nothing else:

{ "name": "ovtest", "version": "1.0.0", "private": true,
  "dependencies": { "node-av": "6.1.1" } }

npm 11.16.0

npm install --package-lock-only --ignore-scripts

package-lock.json contains one entry, node_modules/ip at 2.0.1. No neoip.

pnpm 11.18.0

pnpm install --lockfile-only --ignore-scripts

pnpm-lock.yaml contains ip@2.0.1 (twice, for werift and werift-ice). No neoip.

Yarn 4.16.0

yarn install --mode=update-lockfile

yarn.lock contains:

"ip@npm:^2.0.1":
  version: 2.0.1
  resolution: "ip@npm:2.0.1"

No neoip. Same result on all three.

The three @shinyoshiaki/binary-data → @seydx/binary-data entries are dropped the
same way, so consumers also run the unpatched binary-data rather than the fork.

Note on the pinned version

If the override is reworked, neoip@2.1.0 is worth revisiting. Against the five inputs
named in CVE-2024-29415:

input	ip@2.0.1	neoip@2.1.0	neoip@3.1.0
127.1	public	private	private
01200034567	public	private	private
012.1.2.3	public	private	private
000:0:0000::01	public	private	private
::ffff:127.0.0.1	public	public	private

neoip@2.1.0 still classifies the IPv4-mapped loopback as globally routable; 3.1.0
does not. werift and werift-ice only call isLoopback, isV4Format, isV6Format,
toBuffer and toString, all of which are unchanged in 3.1.0, and its CJS build
carries no __esModule marker so the compiled __importDefault interop in both
packages resolves correctly.

Possible fixes

1. Upstream in werift — the durable fix. werift-ice depends on ip@^2.0.1
   directly; swapping it there for neoip removes the advisory for the whole tree
   rather than for node-av's consumers only.

2. Vendor or fork the affected werift packages if upstream is not responsive.

3. Document the workaround in the README as an immediate mitigation, since it costs
   nothing and unblocks consumers today. Each consumer adds the override at their own
   root:

   npm / pnpm:

   "overrides": { "ip": "npm:neoip@3.1.0" }

   Yarn:

   "resolutions": { "ip": "npm:neoip@3.1.0" }

Happy to open a PR for whichever direction you prefer.

Environment

• node-av 6.1.1
• werift 0.23.0, werift-ice 0.2.2
• Node 26.3.1
• npm 11.16.0, pnpm 11.18.0, Yarn 4.16.0

[seydx]

this will be removed in v6.2.0 since werift does not depend on ip anymore