npm install at the repo root currently leaves npm audit non-clean. Three
advisories are outstanding across the install cascade, all transitive, none
directly declared by us.
What's reported
| Package |
Sev |
Install |
Path |
Vulnerable |
Fixed in |
fast-uri |
high |
root |
ajv@8.18.0 → fast-uri@3.1.5 |
>=3.0.0 <3.1.6 |
3.1.6 |
qs |
moderate |
root |
express@5.2.1 → qs@6.15.3 (also via body-parser) |
>=2.2.5 <6.16.0 |
6.16.0 |
browserslist |
high |
clients/tui |
eslint-plugin-react-hooks@7.1.1 → @babel/core → browserslist@4.28.2 |
<=4.28.6 |
4.28.7+ (latest 4.28.9) |
Advisories:
Reachability — needs confirming, not assumed
Part of the work here is establishing exposure rather than pinning on the
advisory alone. Initial read:
fast-uri is the one that plausibly ships. ajv is a root runtime
dependency that core/json uses to validate schemas coming from the server
under test, and fast-uri is what ajv resolves $id/$ref URIs with — so
the input is attacker-influenced. What is not established is whether any of
these four advisories is exercisable through that path (none of them makes
ajv perform a network fetch). Confirm before treating this as user-facing.
qs looks dev/transitive only. express is a root devDependency and
otherwise arrives under the SDK packages; the web backend is Hono, not
express. If nothing shipped parses a query string through qs, this is
hygiene rather than exposure — worth writing down either way.
browserslist is dev tooling, reached only through tui's ESLint plugin.
Not in any published bundle.
Proposed fix
overrides at the repo root, per the AGENTS.md rule that a transitive is
pinned with an overrides entry and never with npm audit fix (which
resolves an advisory with no upward escape by silently downgrading).
Candidate pins — semver-checked but not yet installed or gate-verified:
fast-uri@4.x exists but is outside ajv's range, so the pin stays on 3.x.
The browserslist copy lives in the clients/tui install, so it needs
either its own override there or a bump of eslint-plugin-react-hooks — decide
which once reachability is written up.
Acceptance
Note on overlap
#2233 / #2243 just landed a workflow that consumes Dependabot alerts into
board-tracked issues. These three may well be re-reported by that sweep — if so,
close whichever is the duplicate rather than fixing both.
npm installat the repo root currently leavesnpm auditnon-clean. Threeadvisories are outstanding across the install cascade, all transitive, none
directly declared by us.
What's reported
fast-uriajv@8.18.0 → fast-uri@3.1.5>=3.0.0 <3.1.63.1.6qsexpress@5.2.1 → qs@6.15.3(also viabody-parser)>=2.2.5 <6.16.06.16.0browserslistclients/tuieslint-plugin-react-hooks@7.1.1 → @babel/core → browserslist@4.28.2<=4.28.64.28.7+ (latest4.28.9)Advisories:
fast-uri— four separate ones: GHSA-5jgf-p345-68v8 (host confusion via skipped IDN canonicalization), GHSA-f65p-4m7j-42xc (SSRF via malformed IPv6 normalization), GHSA-fph4-wmhf-6fwf (SSRF via repeated hostname percent-decoding), GHSA-jqff-g426-hqxp (host confusion via percent-encoded scheme normalization)qs— GHSA-x5fp-wj9c-mxmx (array-limit bypass via bracket-key comma parsing), GHSA-4mjr-xmp4-gh2g (DoS via attacker-controlledisBuffer)browserslist— GHSA-c83g-rgw3-j3cx (unbounded cache growth → OOM), GHSA-73wf-gq98-2v4g (uncaught crash / prototype write via untrustedbrowserslist-stats.json)Reachability — needs confirming, not assumed
Part of the work here is establishing exposure rather than pinning on the
advisory alone. Initial read:
fast-uriis the one that plausibly ships.ajvis a root runtimedependencythatcore/jsonuses to validate schemas coming from the serverunder test, and
fast-uriis whatajvresolves$id/$refURIs with — sothe input is attacker-influenced. What is not established is whether any of
these four advisories is exercisable through that path (none of them makes
ajvperform a network fetch). Confirm before treating this as user-facing.qslooks dev/transitive only.expressis a rootdevDependencyandotherwise arrives under the SDK packages; the web backend is Hono, not
express. If nothing shipped parses a query string through
qs, this ishygiene rather than exposure — worth writing down either way.
browserslistis dev tooling, reached only through tui's ESLint plugin.Not in any published bundle.
Proposed fix
overridesat the repo root, per theAGENTS.mdrule that a transitive ispinned with an
overridesentry and never withnpm audit fix(whichresolves an advisory with no upward escape by silently downgrading).
Candidate pins — semver-checked but not yet installed or gate-verified:
fast-uri@4.xexists but is outsideajv's range, so the pin stays on3.x.The
browserslistcopy lives in theclients/tuiinstall, so it needseither its own override there or a bump of
eslint-plugin-react-hooks— decidewhich once reachability is written up.
Acceptance
npm auditclean at the root and in all four client installsnpm run local:gatepassesNote on overlap
#2233 / #2243 just landed a workflow that consumes Dependabot alerts into
board-tracked issues. These three may well be re-reported by that sweep — if so,
close whichever is the duplicate rather than fixing both.