qs CVE-2026-110816

Exploitation requires the application to re-serialize attacker-influenced data by calling qs.stringify with the NON-DEFAULT arrayFormat:'comma' option (the default 'indices' and the 'brackets'/'repeat' formats are not affected), running an affected qs version 6.7.0 through 6.16.0. The attacker-controlled data must contain an array element that cannot be string-coerced - an object with an own non-callable toString (e.g. {"toString":"x"}) or a null-prototype object. Such elements reach qs.stringify when the app parses input with qs.parse using allowPrototypes:true (the default for Express 4's query parser, Express 5's extended parser, and body-parser's urlencoded({extended:true})) or plainObjects:true, or when it serializes a parsed JSON body. LIMITING FACTORS: default qs.parse options strip the toString key and do NOT throw; no user interaction or authentication is needed, but the non-default comma serialization path must exist in the application. The impact is bounded to a caught 500 error within a framework error boundary; full process termination only occurs where the call runs outside an error boundary (async Express 4 handler yielding an unhandled rejection, or a bare http handler).

This is a genuine but modest-severity denial-of-service issue (CWE-248, uncaught exception), not a high-impact flaw. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N, VC:N/VI:N/VA:L = 6.3) correctly captures the shape: network-reachable and unauthenticated (PR:N), but with an attack requirement (AT:P) and only limited availability impact (VA:L), no confidentiality or integrity impact. The signals are internally consistent and point to low-to-medium real-world risk: publicly available exploit code exists (a working PoC is embedded in the GHSA advisory), but there is NO EPSS score in the provided data and the CVE is NOT listed in CISA KEV, so there is no evidence of active or widespread exploitation. The AT:P requirement is the key limiter - exploitation depends on the application re-serializing attacker-influenced data with qs.stringify using the non-default arrayFormat:'comma' option, so the raw 'AV:N/PR:N' profile overstates practical exposure. The most common outcome is a caught 500 error self-limited to a single request; the process-crash outcome only occurs outside a framework error boundary (e.g. an async Express 4 handler or bare http handler), making worst-case impact dependent on application error handling rather than on qs itself. Net: patch on the normal maintenance cycle - this is not an emergency unless you run the specific vulnerable comma re-serialization pattern outside an error boundary.

An unauthenticated attacker sends an HTTP request containing a crafted parameter such as 'a[0][toString]=x' to an Express/body-parser application (which parse with allowPrototypes:true by default). If the app later rebuilds a query string from the parsed data using qs.stringify with arrayFormat:'comma' - for example to construct a redirect or an upstream request URL - the join/String() coercion of the prototype-key object throws a synchronous TypeError. A working PoC is published in the GHSA advisory; because AC is low and no authentication or user interaction is needed, triggering it is trivial wherever the vulnerable serialization pattern exists.