GHSA-x5fp-wj9c-mxmx: Low severity npm/qs vulnerability
Summary
qs v6.15.3 allows bracket-key input to bypass arrayLimit and throwOnLimitExceeded when comma: true. The input a[]=1,2,3,4 succeeds with arrayLimit: 3, while the equivalent plain-key input is rejected.
Affected version tested:
text qs v6.15.3 commit 18d085e919dae70c8f1b200ab99323058edab2c2
Details
parseArrayValue() enforces the comma limit only for flat values. The a[] form is marked non-flat, so its comma-separated value is wrapped after parsing and the inner array is not checked. A single parameter can therefore materialize arbitrarily large arrays.
PoC
js const qs = require('qs') const options = { comma: true, arrayLimit: 3, throwOnLimitExceeded: true }
const result = qs.parse('a[]=1,2,3,4', options) console.log(result.a[0].length) // 4; expected RangeError
const big = qs.parse('a[]=' + '1,'.repeat(1000000) + '1', { comma: true, arrayLimit: 20 }) console.log(big.a[0].length) // 1000001
On v6.15.3, the first input parses successfully and the second creates an array with 1,000,001 elements. The equivalent a=1,2,3,4 input throws RangeError as expected.
Impact
An attacker who can supply a query string or form body can bypass configured array limits and force excessive memory allocation, causing denial of service. The limit must be applied after comma splitting and before the resulting array is wrapped.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/qsto a version that resolves this vulnerability.Fixed in 6.16.0
Event History
Frequently Asked Questions
Which deployments are exposed to this behavior?
Deployments using qs with comma parsing enabled (comma: true) are exposed when they parse attacker-controlled query strings or form bodies. The bypass specifically uses bracket-key syntax such as a[]=1,2,3,4.
What does an attacker need to exploit it?
An attacker needs only the ability to supply a parsed query string or form body. No authentication or user interaction is indicated by the provided vector.
Why do existing array limits not prevent the issue?
With comma: true, qs applies the comma limit to flat values but not to bracket-key values. As a result, a[] values are wrapped after parsing and the inner comma-separated array is not checked against arrayLimit or throwOnLimitExceeded.
How can I check for the vulnerable parsing path?
Test parsing a[]=1,2,3,4 with comma: true, arrayLimit: 3, and throwOnLimitExceeded: true. On the tested qs v6.15.3 version, this succeeds and produces four elements, whereas a=1,2,3,4 throws a RangeError.