Summary When "qs.parse" is called with "comma: true" and "throwOnLimitExceeded: true", a comma-separated value under a bracket-push key ("a[]=1,2,3,4") is split into an array without being compared against "arrayLimit", while the same value under a flat key ("a=1,2,3,4"), an indexed key ("a[0]="), a nested key ("a[b]="), or a dotted key ("a.b=" with "allowDots") throws the documented "RangeError". A single parameter such as "a[]=1,2,2,..." therefore produces an inner array of arbitrary length even though the caller opted into the hard limit. This is the "[]=" key form that the fix for CVE-2026-2391 (qs 6.14.2) did not cover. Details In "lib/parse.js", a comma-separated value under a "[]=" key is split and then wrapped as a single nested element ("val = [val]", so that each "a[]=x,y" group counts as one element of the outer array). The "arrayLimit" check that 6.14.2 added for comma values runs after that wrap, so for "[]=" parts it only ever saw the wrapper of length 1. 6.15.3 added a pre-split comma count so that an oversized value throws before it is allocated, but gated it on an "isFlatArrayValue" flag that "parseValues" set to "false" for any part containing "[]=", and did not pass it for object-valued input, so the gap remained. PoC Fix "lib/parse.js", applied in 8859c37 on "main" and released as v6.16.0: the "isFlatArrayValue" gate is removed, so every comma-split value is counted against "arrayLimit" before splitting regardless of key form. An in-limit group under "a[]=" still counts as one element of the outer array, and the default ("throwOnLimitExceeded: false") path is unchanged. Affected versions ">=6.14.2 <6.16.0", fixed in v6.16.0. v6.14.2 introduced "arrayLimit" enforcement for comma values (the fix for CVE-2026-2391) but only for values not under a "[]=" key, and every release from v6.14.2 through v6.15.3 has the same gap. v6.14.0 and v6.14.1, where "throwOnLimitExceeded" exists but does not apply to any comma form, are covered by CVE-2026-2391 rather than this record. Earlier lines (6.7.x through 6.13.x) have "comma" but no "throwOnLimitExceeded", so there is no hard cap on any comma path to bypass; releases before 6.7.0 have no "comma" option. Impact An unauthenticated attacker who can reach an application that parses untrusted query strings or urlencoded bodies with both "comma: true" and "throwOnLimitExceeded: true" (both non-default) can bypass the configured limit with a single "a[]=" parameter and force the parser to allocate an array proportional to the request size. The cost is strictly linear in the attacker-supplied bytes (about 0.1 microseconds and 6 to 7 retained bytes per input byte; the same out-of-memory threshold as the documented default "throwOnLimitExceeded: false" path), so a transport-layer request or body size limit bounds it completely (and node's default maximum HTTP header size of 16 KB already bounds the request line, so multi-megabyte payloads need a body parser). The impact is that an opt-in hard limit fails open on one key spelling, not unbounded allocation from a small input.