Dependabot: 6 advisories inside npm's bundled tree (ip-address, undici) — not remediable here, wait for an npm bump in node-red

[windkh]

Six of the seven open Dependabot alerts point at packages vendored inside the npm CLI, which reaches
us as a transitive devDependency of node-red. They are grouped here because they share one remediation
path: none of them can be fixed from this repository.

The advisories

ip-address@10.2.0 — node_modules/npm/node_modules/ip-address, dev: true

Advisory	Severity	Summary	Patched in
GHSA-mwp4-54f8-5fhr	high	Address4 decodes leading-zero octets as decimal	10.3.1
GHSA-22jq-vg5j-6vgg	moderate	Misclassification of IPv4-mapped / NAT64 IPv6 addresses	10.2.1
GHSA-4xrf-jv44-h6hh	moderate	A CIDR suffix suppresses special-use detection	10.2.2

undici@6.27.0 — node_modules/npm/node_modules/undici, dev: true

Advisory	Severity	Summary	Patched in
GHSA-8xcm-r25x-g524	moderate	Downstream response desynchronization via retry	6.28.0
GHSA-m8rv-5g2x-5cg5	moderate	CRLF injection via blob-like body type property	6.28.0
GHSA-v3r7-h72x-cjcm	moderate	Cookie attribute injection via unsanitized domain	6.28.0

Where they come from

node-red-contrib-telegrambot
└─ node-red@5.0.1                    (devDependency)
   └─ @node-red/runtime → @node-red/registry
      └─ npm@11.18.0                 (bundles its own dependency tree)
         ├─ node_modules/ip-address@10.2.0   dev: true
         └─ node_modules/undici@6.27.0       dev: true

Our own copies are not affected

This is the part worth stating plainly, because the package names are alarming and the versions are not the
ones we ship:

Package	Ours (production)	Flagged (dev, inside npm)
ip-address	10.4.0 — above all three fix versions	10.2.0
undici	7.29.0 — the 6.x advisories do not apply	6.27.0

Our ip-address arrives through fetch-socks → socks and is a genuine runtime dependency — but it is
already patched in package-lock.json. (A stale local node_modules can show 10.2.0 there and look like a
runtime exposure; the lockfile is the authority.)

Why this cannot be fixed here

npm bundles its dependencies: they are shipped inside the npm tarball rather than resolved from the
registry. overrides do not reach into a bundled tree, so the remediation used in
ADR 0006 does not apply. The chain is:

1. npm releases a version with the patched vendored copies, then
2. node-red bumps its npm dependency, then
3. Dependabot proposes that bump here and the alerts close on their own.

Exposure

Effectively none for users, and low for us. These live in the dev tree only; the published tarball ships
telegrambot/ and examples/ with three runtime dependencies. The vendored copies are exercised only when
npm itself installs packages — i.e. during npm ci on CI and locally.

Action

Wait. Track here so the alert count is explained rather than re-investigated each time it appears in a
push warning. Close when the alerts clear after a node-red bump.

---

Filed while triaging the seven open Dependabot alerts. The seventh (js-yaml, high) is tracked separately —
it has a remediation option that these do not.

[windkh]

Status check — the six are unchanged, but the alert count is no longer six.

Nine alerts are open. The six this issue tracks (ip-address ×3, undici ×3) are exactly as described: still inside node_modules/npm/node_modules/, still not remediable from here.

Three new ones are a different case and are already fixed. jsonata picked up three critical advisories:

Advisory	Patched in
GHSA-8gq3-vp5j-2grp	2.2.0
GHSA-2943-5xfg-gq5f	2.2.1
GHSA-66mm-25pp-rfff	2.2.1

They do not belong to this issue, because jsonata is not bundled:

node-red@5.0.4 -> @node-red/util@5.0.4 -> jsonata@2.0.6

That is an ordinary transitive dependency. @node-red/util pins it at exactly 2.0.6, so deduplication cannot lift it — but an overrides entry can, which is the situation ADR 0006 exists for. Upstream has no fix yet: 5.0.4 is the newest node-red, and @node-red/util@latest still pins 2.0.6.

Fixed in ce7d16b with "jsonata": "^2.2.1", resolved to 2.2.2. Verified with the bump in place: lint, format:check, 305 tests and coverage:check green.

What still separates the two groups, and why this issue stays open: an override reaches a resolved tree, not a vendored one. npm ships its dependencies inside its own tarball so it can install itself, so the six here need npm to publish patched copies, node-red to bump npm, and Dependabot to propose that bump — none of which is an action available in this repository.

Exposure is unchanged for all nine: every one is dev scope. The published tarball ships telegrambot/ and examples/ with three runtime dependencies, so nothing reaches users through us. A user's jsonata comes from their own Node-RED install, which no override here can touch — the fix above buys a clean alert list, not user-facing security.