Source: node-qs
Version: 6.16.0+ds+~6.15.1-1
X-Debbugs-CC: [email protected]
Severity: important
Tags: security upstream
Forwarded: https://github.com/ljharb/qs/issues/626
Control: found -1 6.13.0+ds+~6.9.16-1
Hi,
The following vulnerability was published for node-qs.
CVE-2026-110910[0]:
| ### Summary `qs.stringify` with `allowEmptyArrays: true` writes
| the key of an empty array without encoding it, even though keys are
| encoded by default. A key that contains `&` (or the configured
| `delimiter`), `=`, or `#` therefore becomes query string syntax
| instead of data, so a caller-supplied key name can add parameters to
| the serialized query string, or cut it short. ### Details In
| `lib/stringify.js`, the `allowEmptyArrays` branch returns
| `adjustedPrefix + '[]'` early, before the code that passes every
| other key through `encoder` and `formatter`. So `{ "x&k=v": ["1"] }`
| serializes as `x%26k%3Dv%5B0%5D=1`, but `{ "x&k=v": [] }` serializes
| as `x&k=v[]`. The early return applies at any depth (`{ "a": {
| "b&k=v": [] } }` gives `a[b&k=v][]`), under every `arrayFormat`,
| with `allowDots`, and with a custom `encoder`, which is never called
| for that key. With `encode: false` or `encodeValuesOnly: true`, keys
| are intentionally left unencoded on every path; those configurations
| are not affected. #### PoC ```js var qs = require("qs");
| var query = qs.stringify({ q: "hi", "x&apiKey=evil&y": [] }, {
| allowEmptyArrays: true }); // "q=hi&x&apiKey=evil&y[]"
| qs.parse(query); // { q: "hi", x: "", apiKey: "evil", y: [""] }
| qs.stringify({ "x#": [], z: "1" }, { allowEmptyArrays: true });
| // "x#[]&z=1": in a URL, everything after "#" becomes the fragment
| ``` #### Fix Applied in 234d505 on `main` and released as
| v6.17.0, and backported to v6.16.2, v6.15.4, v6.14.3, v6.13.4, and
| v6.12.6: the key of an empty array goes through `encoder` and
| `formatter` exactly as the key of any other value does, so `{
| "x&apiKey=evil&y": [] }` now serializes as
| `x%26apiKey%3Devil%26y[]`. Keys that need no encoding serialize as
| before, with two exceptions that match every other path: the
| brackets of a nested key are now encoded (`a[b][]` becomes
| `a%5Bb%5D[]`, which `qs.parse` reads identically), and with
| `encodeDotInKeys`, a dot in the key becomes `%252E` instead of `%2E`
| (which `decodeDotInKeys` previously misread as nesting). ###
| Affected versions - `>=6.12.0 <6.12.6`, fixed in v6.12.6 -
| `>=6.13.0 <6.13.4`, fixed in v6.13.4 - `>=6.14.0 <6.14.3`, fixed
| in v6.14.3 - `>=6.15.0 <6.15.4`, fixed in v6.15.4 - `>=6.16.0
| <6.16.2`, fixed in v6.16.2 v6.17.0 and later are not affected.
| `allowEmptyArrays` was introduced in f22b2bc and first shipped in
| v6.12.0, with this early return. Earlier versions have no
| `allowEmptyArrays` option and are not affected. ### Impact An
| application that passes an object whose key names come from
| untrusted input to `qs.stringify` with `allowEmptyArrays: true` (for
| example, to forward a parsed JSON body or user-selected fields to an
| upstream service) can have parameters injected into the resulting
| query string. The injected parameters are not keys of the object, so
| deleting or overwriting a key on the object (such as setting a
| trusted `apiKey` after copying the user's fields) does not remove
| them; whether the attacker's value or the application's wins depends
| on how the receiving side handles a duplicate parameter. A `#` in
| such a key ends the query string early when the result is placed in
| a URL. `allowEmptyArrays` is off by default, and only keys whose
| value (after any `filter`) is an empty array are affected.
If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2026-110910
https://www.cve.org/CVERecord?id=CVE-2026-110910
[1] https://github.com/ljharb/qs/issues/626
[2] https://github.com/ljharb/qs/security/advisories/GHSA-w4cr-vjpx-p82q
[3] https://github.com/ljharb/qs/commit/5d3b1b9ec6afd0cfc760c8e12862873789a32fc8
Please adjust the affected versions in the BTS as needed.
Regards,
Salvatore
