Express 4.22.2 has qs vulnerable dependency

[samarth444]

Environment information

Version: 4.22.2

Platform: x86, x64

Node.js version: "node": ">= 0.10.0"

Any other relevant information:

What steps will reproduce the bug?

express 4.22.2 uses qs 6.15.2 version as dependency, where qs 6.15.2 is reported as vulnerability as
CVE-2026-82417, CVE-2026-82562
https://security.snyk.io/package/npm/qs

[cj-sadrul-nashid]

This is confirmed to be a body-parser-level pinning issue, not just a matter of qs having a vulnerable version.

express@4.22.2 depends on body-parser@~1.20.5, and body-parser@1.20.6 (the current latest 1.x) declares:

"qs": "~6.15.1"

That tilde range only resolves to qs >=6.15.1 <6.16.0 — it structurally excludes 6.16.0, which is the fix version for the qs vulnerabilities referenced above. So even running npm update / npm audit fix against express@4.x cannot pull in a patched qs; the range itself blocks it.

body-parser@2.x (used by express@5.x) already declares a wider "qs": "^6.15.2", which does allow 6.16.0.

I've filed the range-widening request against body-parser directly: https://github.com/expressjs/body-parser/issues/765

Once that's addressed there, express@4.x would also need to bump its body-parser dependency range to pick up the fixed release. Until both land, the only way to get a patched qs on express@4.x is a manual overrides/resolutions entry in the consuming project's package.json, which bypasses body-parser's own declared compatibility range.

[MarkushaRaz]

Hi @samarth444! Thanks for reporting this. I’d like to take on this task.

Judging by package.json, the qs package version is pinned to ^6.14.0, which causes npm install to install the vulnerable version 6.15.2. Both vulnerabilities (CVEs) are fixed in qs version 6.16.0, so updating the minimum version to ^6.16.0 and updating package-lock.json should resolve the issue.

It is worth noting that pull request #7305 is already open; it bumps the qs version, but only to 6.15.2—a version that remains vulnerable to both CVEs mentioned here—so that PR alone won't resolve the issue.

I will create a pull request shortly.

[MarkushaRaz]

Follow-up to my comment above — thanks @cj-sadrul-nashid for digging into this, that's an important catch.

Since #7440 already covers widening express's own qs range, opening another PR for that here would just duplicate it. The remaining gap is on the body-parser side (expressjs/body-parser#765), which is what actually blocks a patched qs from reaching req.body. I'll redirect my contribution there instead and open a PR against body-parser bumping qs from ~6.15.1 to ~6.16.0, then come back here once that's landed to help bump express's body-parser range in a follow-up PR.

[qwilr-altonius]

Follow-up to my comment above — thanks @cj-sadrul-nashid for digging into this, that's an important catch.

Since #7440 already covers widening express's own qs range, opening another PR for that here would just duplicate it. The remaining gap is on the body-parser side (expressjs/body-parser#765), which is what actually blocks a patched qs from reaching req.body. I'll redirect my contribution there instead and open a PR against body-parser bumping qs from ~6.15.1 to ~6.16.0, then come back here once that's landed to help bump express's body-parser range in a follow-up PR.

@MarkushaRaz body-parser has updated to 1.20.8 and with it the version of qs

[usualdesigner]

While you're waiting on Express to bump its pin: npm overrides (or pnpm/yarn resolutions) let you force a patched qs version without forking anything - "overrides": { "qs": "^6.x.x-patched" } in package.json. Just double check whatever qs version you pin is actually compatible with Express's usage (extended query parsing), it's an internal dependency, not something your own code calls directly, so mismatches would show up as parsing bugs, not type errors.