Skip to content

chore: pin browserslist past GHSA-c83g-rgw3-j3cx in clients/tui (dev-only high advisory) #2225

Closed
#2249
Closed
chore: pin browserslist past GHSA-c83g-rgw3-j3cx in clients/tui (dev-only high advisory)#2225
#2249
Assignees
cliffhall
Labels
choreMaintenance: deps, build tooling, CI, cleanup — no user-facing behavior changev2Issues and PRs for v2
Milestone
v2.6.0

Description

@cliffhall
cliffhall
opened on Sep 2, 2026

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=dev in clients/tui — 0 vulnerabilities.
  • The tarball ships only each client's build/; pack:verify installs 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 audit reports 0 vulnerabilities in all five installs, dev included
  • npm audit --omit=dev still clean in all five
  • npm run local:gate passes (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

  1. cliffhall
    added this to the v2.6.0 milestone on Sep 2, 2026
  2. cliffhall
    added
    v2Issues and PRs for v2
    choreMaintenance: deps, build tooling, CI, cleanup — no user-facing behavior change
    on Sep 2, 2026

  3. cliffhall commented on Sep 2, 2026

    @cliffhall
    cliffhall
    on Sep 2, 2026
    MemberAuthor

    Triage: Priority Medium (total 6)

    • Severity 2 — minor friction with an easy workaround. The advisory is real but the exposure is not: browserslist reaches only the tui dev install, npm audit --omit=dev is clean there, and the tarball ships only each client's build/. Neither GHSA is reachable in our use (we feed it no untrusted browserslist-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) keeps npm audit non-clean in web/cli/tui #2062 established — npm audit clean across all five installs, dev included.
    • Urgency 3 — wanted this milestone. Nothing blocks on it and it does not affect the v2.5.0 release, but a permanently-dirty npm audit is 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.
    • Bonuses: +1 security-related. Claimed on substance, not on the label: the type label is 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.
    • Not claimed: no bug label, no engagement yet, unassigned, not a sub-issue, and no milestone bonus — every issue filed through /issue-create carries 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.

  4. cliffhall
    added a commit that references this issue on Sep 5, 2026

    chore(deps): refresh fast-uri, qs and browserslist to clear npm audit

    1018d81
  5. cliffhall
    self-assigned this
    on Sep 5, 2026
  6. cliffhall
    linked a pull request that will close this issuechore(deps): refresh fast-uri, qs and browserslist to clear npm audit #2249on Sep 5, 2026
  7. cliffhall
    closed this as completedon Sep 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

choreMaintenance: deps, build tooling, CI, cleanup — no user-facing behavior changev2Issues and PRs for v2

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions