deps: qs@~6.16.0

[lazerg]

4.x declares qs as ~6.15.1, which caps at 6.15.3. Both CVE-2026-82417 (GHSA-4mjr-xmp4-gh2g, affects >= 2.2.5, <= 6.15.3) and CVE-2026-82562 (GHSA-x5fp-wj9c-mxmx, affects >= 6.14.2, <= 6.15.3) are patched in qs@6.16.0, so a fresh npm install express@4.22.2 still lands on a vulnerable qs.

Neither advisory is triggerable through Express itself. Express only calls qs.parse, and the first one needs qs.stringify. The second needs comma: true together with throwOnLimitExceeded: true, which Express never sets. The bump still moves the shipped qs to a version scanners do not flag.

Both advisories are recent enough that they haven't reached the feed npm audit reads, so it still reports 0 vulnerabilities here. The GHSA pages carry the affected ranges.

This covers the direct dependency only. body-parser@1.20.6, which is what ~1.20.5 resolves to, still declares qs: ~6.15.1 of its own, so its nested copy stays on 6.15.3 until expressjs/body-parser#761 lands. Referencing rather than closing #7439 for that reason.

Refs #7439

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​qs@​6.16.0

View full report

[krzysdz]

The first one is reachable through the extended query parser, since parseExtendedQueryString in lib/utils.js passes allowPrototypes: true.

GHSA-4mjr-xmp4-gh2g affects qs.stringify(), so it's not really reachable through Express, which uses only the parser. The reference to allowPrototypes: true is there, because this option is necessary to construct an object that can trigger the DoS (unexpected error) when using qs.parse() -> qs.stringify() round trip.

This covers the direct dependency only. body-parser@1.20.6, which is what ~1.20.5 resolves to, still declares qs: ~6.15.1 of its own, so its nested copy stays on 6.15.3 until that repo bumps too.

expressjs/body-parser#761

[lazerg]

You're right, and I dropped that line from the description. Express only calls qs.parse, so the stringify issue sits outside its path. The arrayLimit bypass needs comma: true with throwOnLimitExceeded: true, which Express never sets either. Grepping the tree, the only qs.stringify callers are superagent and formidable, both test-only.

So this is a bump of the shipped dependency, not a patch for a live hole in 4.x. The description says that now, and points at expressjs/body-parser#761 for the nested copy.