Repository navigation
chore: pin browserslist past GHSA-c83g-rgw3-j3cx in clients/tui (dev-only high advisory) #2225
Description
npm audit is clean in four of the five installs and reports 1 high in clients/tui:
browserslist <=4.28.6
Severity: high
GHSA-c83g-rgw3-j3cx — unbounded memory growth (no cache eviction) via distinct query results, eventual OOM
GHSA-73wf-gq98-2v4g — uncaught crash / prototype write via untrusted browserslist-stats.json (normalizeStats)
node_modules/browserslist
Where it comes from
It is transitive, through the tui-local ESLint plugin:
@modelcontextprotocol/inspector-tui
└─┬ eslint-plugin-react-hooks@7.1.1
└─┬ @babel/core@7.29.7
└─┬ @babel/helper-compilation-targets@7.29.7
└─┬ browserslist@4.28.2
└─┬ update-browserslist-db@1.2.3
└── browserslist@4.28.2 deduped
This is exactly the peer-shadow case AGENTS.md already documents under
Dependency placement: deleting a root-only
declaration does not delete the client copy, because npm auto-installs an unmet peer into
the install that needs it, and a client-only ESLint plugin drags a client-local tree in with it.
Nothing published is affected
npm audit --omit=devinclients/tui— 0 vulnerabilities.- The tarball ships only each client's
build/;pack:verifyinstalls clean into a throwaway
consumer and drives web/cli/tui end to end.
It is not new to v2.5.0
origin/main's tui lockfile pins the same browserslist@4.28.2, so v2.4.0 shipped with this
exact tree — the advisory was published since. The root (4.28.8) and clients/web
(4.28.7) copies float above the 4.28.7 fix line only because #2200 / #2196 refreshed their
lockfiles in this milestone while tui's was not touched.
So this is a reporting change, not a regression, and it does not block the v2.5.0 release
(#2214). But it does mean npm audit across the five installs is no longer clean, which is the
state #2062 established and which the v2.4.0 smoke ledger recorded.
Fix
Per AGENTS.md: pin a transitive with an overrides entry, not with npm audit fix —
which "resolves" an advisory with no upward escape by silently downgrading. clients/tui
already carries an overrides block (ink-select-input, esbuild), so this is one more entry:
"overrides": { "browserslist": "^4.28.7" }Done when
-
npm auditreports 0 vulnerabilities in all five installs, dev included -
npm audit --omit=devstill clean in all five -
npm run local:gatepasses (the tui lint stage is what pulls the plugin in)
Found while smoke-testing the v2.5.0 payload — see the note on
#2215 (comment)
Activity
cliffhall commentedon Sep 2, 2026
Triage: Priority Medium (total 6)
browserslistreaches only the tui dev install,npm audit --omit=devis clean there, and the tarball ships only each client'sbuild/. Neither GHSA is reachable in our use (we feed it no untrustedbrowserslist-stats.json, and the OOM is bounded by a lint run). What is actually broken is the invariant Dev-only esbuild advisory (GHSA-g7r4-m6w7-qqqr) keepsnpm auditnon-clean in web/cli/tui #2062 established —npm auditclean across all five installs, dev included.npm auditis a channel people learn to skim, which is the same argument Fail lint on warnings (--max-warnings 0): a warn-level rule let a stale-closure bug reach review #2085 and the build-output rule make.chore(correct — no user-facing behavior change), but the issue is a published CVE pair. Flagging it so a re-scorer can disagree with that call rather than have to reverse-engineer it.buglabel, no engagement yet, unassigned, not a sub-issue, and no milestone bonus — every issue filed through/issue-createcarries a milestone by rule, so counting it here would make it a constant that discriminates nothing.Band note: this scores Medium because it is dev-only and unshipped. Had the same advisory reached the published tarball it would be Severity 5 and land High or Urgent.
Board: #28, Status
Todo, milestone v2.6.0.chore(deps): refresh fast-uri, qs and browserslist to clear npm audit