qs npm hits DoS CVE-2026-8723

The qs npm package is carrying a newly disclosed denial-of-service flaw that can crash a Node.js process under a narrow but realistic set of conditions. GitHub’s advisory database lists the issue as CVE-2026-8723 and says affected versions are 6.11.1 through 6.15.1, with a patched release in 6.15.2. The bug sits in `qs.stringify`, not the parser path many developers first associate with query-string risk. GitHub’s reviewed advisory says the crash happens when application code calls `qs.stringify` with `arrayFormat: 'comma'` and `encodeValuesOnly: true` on an array that contains `null` or `undefined`. (github.com) That matters because `qs` is widely used in the Node.js ecosystem. The npm package page showed about 18,297 dependent projects when it was last crawled, making the flaw relevant anywhere the library is used to serialize user-influenced data into URLs or downstream requests. ### How does the crash actually happen? GitHub’s advisory says the vulnerable code path maps array values through the encoder before joining them into a comma-separated string. (github.com) In that branch, `utils.encode` reads `str.length` without guarding against `null` or `undefined`, which causes a synchronous `TypeError` instead of returning a serialized query string. (npmjs.com) The proof-of-concept in the advisory is small. A call that stringifies an object such as `{ a: [null, 'b'] }` with the two non-default options enabled is enough to trigger the exception. GitHub says the error is synchronous, which means an unhandled throw can terminate the process or at least fail the request path immediately, depending on how the application is supervised. (github.com) ### Why is this being described as a denial-of-service issue? GitHub classifies the issue as a remotely triggerable DoS because the crash can be reached through application behavior, not just through local misuse of the library. The advisory says any application code that accepts attacker-controlled or attacker-influenced array values and then serializes them with that option pair can be forced into the throwing path. (github.com) The scope is narrower than “all qs usage.” The two required options — `arrayFormat: 'comma'` and `encodeValuesOnly: true` — are both non-default, and earlier versions including 6.11.0 and older 6.10.x, 6.9.x, 6.8.x and 6.7.x lines are not affected, according to GitHub’s advisory. ### Why don’t the library’s null-handling options save it? (github.com) GitHub’s advisory says `skipNulls` and `strictNullHandling` do not prevent this crash because both checks sit later in the per-element loop. The exception is thrown before those options get a chance to run. That detail is the key operational point for developers reviewing exposure. (github.com) Code that appears to account for nullable values may still be vulnerable if it relies on those options while also using the affected serialization branch. ### What changed in the fix? GitHub says the patched release, qs 6.15.2, changes the mapping step so `null` and `undefined` pass through unchanged instead of being sent directly to the encoder. (github.com) The advisory traces the vulnerable code shape back to commit `4c4b23d`, introduced on January 19, 2023, and says the fix was applied in commit `21f80b3` and released in 6.15.2. For teams checking next steps, the practical action is specific: identify any use of `qs.stringify` with `arrayFormat: 'comma'` and `encodeValuesOnly: true`, then move to 6.15.2 or later. GitHub’s reviewed advisory page for GHSA-q8mj-m7cp-5q26 and the package’s release stream are the two places to watch for any follow-on updates. (github.com)