Bump transitive proxy-addr to 2.0.8 (CVE-2026-90711)

[phoenix-server]

Summary

proxy-addr@2.0.7 resolves into this tree via express@4.22.1 — see pnpm-lock.yaml, proxy-addr@2.0.7 at the dependency edge under express. That version is affected by CVE-2026-90711 (GHSA-jqcg-44mw-7w3h, Aikido AIKIDO-2026-101201, scored critical), fixed in 2.0.8.

The defect

proxy-addr accepts an IPv4-mapped IPv6 trust subnet with an IPv4-sized prefix — ::ffff:10.0.0.0/8 instead of ::ffff:10.0.0.0/104 — and treats that as trusting every IPv4 address. The socket peer is then counted as hop 0, so any unauthenticated client can set X-Forwarded-For to an arbitrary address. Everything built on the resolved client IP — IP allow-lists, rate limiting, geolocation, audit logging — becomes spoofable.

Exposure here: low, but not zero

• createWebApp() in src/factories/web-app-factory.ts calls express() and never sets trust proxy, so Express keeps its default of false and req.ip is the socket peer. The relay's own client-IP logic does not go through Express at all: it uses getRemoteAddress() / isTrustedProxy() in src/utils/http.ts, which trust a forwarded header only against configured proxies — the hardening from fix: only trust forwarded IP header from configured trusted proxies #493.
• But request.ip is read directly in src/controllers/admin/post-settings-restore-controller.ts:21 and src/controllers/admin/patch-settings-controller.ts:73. In any deployment that sets trust proxy to a proxy subnet — the common pattern behind Cloudflare or nginx, and frequently written in IPv4-mapped IPv6 notation — proxy-addr becomes load-bearing for those paths, and that is precisely the configuration this CVE turns into an authentication bypass.

Fix

express@4.22.1 declares ~2.0.7 and express@5.x declares ^2.0.7; both already accept 2.0.8, so no framework change is needed. This repo already carries a pnpm overrides block (serialize-javascript), so it is one line:

"pnpm": { "overrides": { "proxy-addr": "^2.0.8" } }

then pnpm install to refresh the lockfile and pnpm why proxy-addr to confirm 2.0.8 resolves.

Not urgent for a default deployment, but it is a zero-risk bump that closes the class outright, and cheaper now than reasoning about each operator's proxy configuration later.

---

Advisory: https://intel.aikido.dev/cve/AIKIDO-2026-101201 · Upstream: GHSA-jqcg-44mw-7w3h

One pnpm note, from doing this on cameri/akkadian-agent minutes after filing. At the pnpm@10.33.0 this repo pins, the package.json pnpm.overrides field above works — the existing serialize-javascript override proves it (declared >=7.0.3 <8, resolved 7.0.5 in the lockfile). But pnpm 11 no longer reads that field at all; it warns The "pnpm" field in package.json is no longer read by pnpm ... "pnpm.overrides" and ignores the setting. My first attempt there failed that way, and what caught it was pnpm install refusing with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH — a frozen install compares the override config against the lockfile, so a silently-ignored override cannot reach a commit. When this repo moves to pnpm 11, the overrides block has to move to pnpm-workspace.yaml (akkadian-agent got one that way, entry written in the same pkg@range: '>=version' style as its existing list).