GHSA-6rw7-vpxm-498p is not a high severity vulnerability

[kroleg]

GHSA-6rw7-vpxm-498p

While it's true that arrayLimit is bypassed it won't cause DoS with single request because qs also has parameterLimit option set to 1000 by default which prevents from returning bigger arrays. Source: https://github.com/ljharb/qs/blob/main/lib/parse.js#L66-L70.

Is it a bug? Yes. Is it a high severity memory exhaustion vulnerability? I highly doubt that

If we consider usage of arrays of 1000 items as memory intensive how using objects with 1000 keys (qs returns objects instead of arrays if number of items exceeds arrayLimit) preventing memory exhaustion?

So several claims in vulnerability description are false:

1. Test 2 - DoS demonstration

claims that result.a.length will be 10000 but on practice it will be equal to 1000 because of parameterLimit option kicking in (linked above)

So if you run it

// poc.js
const qs = require('qs');

// adding to make sure correct version is tested
console.log('qs version:', require('qs/package.json').version);
console.log('');

// this part copied from vulnerability desc
const attack = 'a[]=' + Array(10000).fill('x').join('&a[]=');
const result = qs.parse(attack, { arrayLimit: 100 });
console.log(result.a.length);  // Output: 10000 (should be max 100)

it outputs:

code/test-qs-dos $ node poc.js
qs version: 6.14.0

1000

2. In "Attack scenario"

qs ignores limit, parses all 100,000 elements into array

nope, it will return array with first 1000 elements. And ofc it won't exhaust memory.

3. "Single malicious request can crash server"

not true. Array with 1000 elements can't crush server

[JonathanLEvans]

Hi @kroleg,

Thank you for your concern. GHSA-6rw7-vpxm-498p comes directly from qs's own advisory published by @ljharb. If you think they made a mistake, you should reach out to qs directly.

[kroleg]

So there is no way to take it down if maintainer refuses to admit that it's not a vulnerability?