ChangeIntel IT change radar
Public mode

No access to your tenant or devices. Every item links to its source. What this means

Sources need attention Customize Public modeDiscuss ChangeIntel on Discord
CVE-2026-82562

qs · Vulnerability

CVSS 3.1 3.7 LOWCVSS 4.0 6.3 MEDIUMEUVD CVSS 4.0 6.3 CVSS 4.0 · 7ffcee3d-2c14-4c3e-b844-86c6a321a158 · Secondary 6.3 MEDIUMCVSS 3.1 · 7ffcee3d-2c14-4c3e-b844-86c6a321a158 · Secondary 3.7 LOWCVSS_V3 CVSS_V4 Publisher rating MODERATEFixed by qs 6.16.0KEV status unknown
Original advisory

cve-program · CVE-2026-82562

Published

### 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 ```js var qs = require('qs'); var options = { comma: true, arrayLimit: 3, throwOnLimitExceeded: true }; qs.parse('a=1,2,3,4', options); // RangeError: Array limit exceeded. Only 3 elements allowed in an array. qs.parse('a[]=1,2,3,4', options); // { a: [ [ '1', '2', '3', '4' ] ] } (no throw) qs.parse('a[]=' + '1,'.repeat(1000000) + '1', { comma: true, arrayLimit: 20, throwOnLimitExceeded: true }); // no throw; a 1,000,001-element inner array is allocated ``` #### 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.

Read the publisher's advisory

euvd · EUVD-2026-68141

Published

### 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 ```js var qs = require('qs'); var options = { comma: true, arrayLimit: 3, throwOnLimitExceeded: true }; qs.parse('a=1,2,3,4', options); // RangeError: Array limit exceeded. Only 3 elements allowed in an array. qs.parse('a[]=1,2,3,4', options); // { a: [ [ '1', '2', '3', '4' ] ] } (no throw) qs.parse('a[]=' + '1,'.repeat(1000000) + '1', { comma: true, arrayLimit: 20, throwOnLimitExceeded: true }); // no throw; a 1,000,001-element inner array is allocated ``` #### 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.

Read the publisher's advisory

nvd · CVE-2026-82562

Published

### 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 ```js var qs = require('qs'); var options = { comma: true, arrayLimit: 3, throwOnLimitExceeded: true }; qs.parse('a=1,2,3,4', options); // RangeError: Array limit exceeded. Only 3 elements allowed in an array. qs.parse('a[]=1,2,3,4', options); // { a: [ [ '1', '2', '3', '4' ] ] } (no throw) qs.parse('a[]=' + '1,'.repeat(1000000) + '1', { comma: true, arrayLimit: 20, throwOnLimitExceeded: true }); // no throw; a 1,000,001-element inner array is allocated ``` #### 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.

Read the publisher's advisory

osv · GHSA-x5fp-wj9c-mxmx

Published

### 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.

Read the publisher's advisory

Affected versions, risk and source history

Exploitation and risk

Source status

CISA KEV lists vulnerabilities known to be exploited. FIRST EPSS estimates the likelihood of exploitation in the next 30 days. An unavailable score does not mean zero risk.

Which CVEs have scores here?

This view includes predictions for CVE identifiers explicitly listed in public NuGet advisories. Microsoft release pages have their own prediction coverage. Check source status for the scope and latest checks.

No exploitation or prediction data is available here for these CVEs. This does not mean they are safe or unlikely to be exploited.

cve-program · CVE-2026-82562

Published

qs.parse does not enforce arrayLimit on comma groups under bracket-push keys when throwOnLimitExceeded is set (incomplete fix for CVE-2026-2391)

### 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 ```js var qs = require('qs'); var options = { comma: true, arrayLimit: 3, throwOnLimitExceeded: true }; qs.parse('a=1,2,3,4', options); // RangeError: Array limit exceeded. Only 3 elements allowed in an array. qs.parse('a[]=1,2,3,4', options); // { a: [ [ '1', '2', '3', '4' ] ] } (no throw) qs.parse('a[]=' + '1,'.repeat(1000000) + '1', { comma: true, arrayLimit: 20, throwOnLimitExceeded: true }); // no throw; a 1,000,001-element inner array is allocated ``` #### 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.

Source published
29 Aug 2026 23:58:31 UTC
Source modified
31 Aug 2026 17:04:14 UTC
Saved here
23 Oct 2026 15:48:27 UTC
Source terms
CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

Source: cve-program · CVE Program Terms of Use. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 3.1 · 3.7 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

CVSS 4.0 · 6.3 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

euvd · EUVD-2026-68141

Published

### Summary

### 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 ```js var qs = require('qs'); var options = { comma: true, arrayLimit: 3, throwOnLimitExceeded: true }; qs.parse('a=1,2,3,4', options); // RangeError: Array limit exceeded. Only 3 elements allowed in an array. qs.parse('a[]=1,2,3,4', options); // { a: [ [ '1', '2', '3', '4' ] ] } (no throw) qs.parse('a[]=' + '1,'.repeat(1000000) + '1', { comma: true, arrayLimit: 20, throwOnLimitExceeded: true }); // no throw; a 1,000,001-element inner array is allocated ``` #### 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.

Additional publisher context

EUVD source date text has no stated timezone and is retained without inventing a UTC instant. Related bulletin membership is not an alias, common cause or applicability claim. A missing vector with a zero score is treated as unrated. Complete vendor/product and underlying source evidence remains in the original JSON.

Original publisher date fields

datePublished: Aug 29, 2026, 11:58:31 PM

dateUpdated: Aug 31, 2026, 5:04:14 PM

8 related source bulletins · separate from aliases

RHSA-2026:63164: Red Hat Security Advisory: Red Hat Hardened Images RPMs bug fix and enhancement update

CVE-2026-8595 · CVE-2026-8609 · CVE-2026-9765 · CVE-2026-17033 · CVE-2026-19197 · CVE-2026-21723 · CVE-2026-33382 · CVE-2026-82417 · CVE-2026-82562 · CVE-2026-84375

WID-SEC-W-2026-3623: IBM DataPower Gateway: Mehrere Schwachstellen

CVE-2023-53781 · CVE-2025-14087 · CVE-2025-14512 · CVE-2025-21858 · CVE-2025-22105 · CVE-2025-37980 · CVE-2025-38015 · CVE-2025-38097 · CVE-2025-38180 · CVE-2025-38400 · CVE-2025-38405 · CVE-2025-38441 · CVE-2025-38470 · CVE-2025-38653 · CVE-2025-39766 · CVE-2025-39797 · CVE-2025-39866 · CVE-2025-40134 · CVE-2025-48431 · CVE-2025-5278 · CVE-2025-68183 · CVE-2025-68211 · CVE-2025-68214 · CVE-2025-68347 · CVE-2025-68366 · CVE-2025-68724 · CVE-2025-71066 · CVE-2025-71089 · CVE-2026-12143 · CVE-2026-13257 · CVE-2026-13258 · CVE-2026-13757 · CVE-2026-14269 · CVE-2026-14273 · CVE-2026-14496 · CVE-2026-14497 · CVE-2026-14502 · CVE-2026-14507 · CVE-2026-14508 · CVE-2026-14509 · CVE-2026-14888 · CVE-2026-14905 · CVE-2026-14988 · CVE-2026-14990 · CVE-2026-14991 · CVE-2026-14992 · CVE-2026-14999 · CVE-2026-15588 · CVE-2026-15762 · CVE-2026-15781 · CVE-2026-15784 · CVE-2026-15819 · CVE-2026-15822 · CVE-2026-15824 · CVE-2026-16111 · CVE-2026-16159 · CVE-2026-16161 · CVE-2026-16163 · CVE-2026-16164 · CVE-2026-16165 · CVE-2026-16167 · CVE-2026-16169 · CVE-2026-16170 · CVE-2026-16176 · CVE-2026-16177 · CVE-2026-16178 · CVE-2026-16179 · CVE-2026-16181 · CVE-2026-16182 · CVE-2026-16340 · CVE-2026-16439 · CVE-2026-16440 · CVE-2026-16441 · CVE-2026-2100 · CVE-2026-22979 · CVE-2026-22984 · CVE-2026-22990 · CVE-2026-23002 · CVE-2026-23060 · CVE-2026-23110 · CVE-2026-23204 · CVE-2026-23209 · CVE-2026-23216 · CVE-2026-23243 · CVE-2026-23270 · CVE-2026-23392 · CVE-2026-23455 · CVE-2026-2391 · CVE-2026-31411 · CVE-2026-31419 · CVE-2026-31488 · CVE-2026-31508 · CVE-2026-31532 · CVE-2026-31581 · CVE-2026-31607 · CVE-2026-31613 · CVE-2026-31669 · CVE-2026-31677 · CVE-2026-31684 · CVE-2026-31685 · CVE-2026-33845 · CVE-2026-33846 · CVE-2026-3832 · CVE-2026-3833 · CVE-2026-4046 · CVE-2026-41254 · CVE-2026-41602 · CVE-2026-41606 · CVE-2026-41607 · CVE-2026-42009 · CVE-2026-42010 · CVE-2026-42011 · CVE-2026-42012 · CVE-2026-42013 · CVE-2026-42014 · CVE-2026-42015 · CVE-2026-43027 · CVE-2026-43037 · CVE-2026-43038 · CVE-2026-43056 · CVE-2026-43074 · CVE-2026-43116 · CVE-2026-43125 · CVE-2026-43163 · CVE-2026-43190 · CVE-2026-43198 · CVE-2026-43260 · CVE-2026-43284 · CVE-2026-43303 · CVE-2026-43329 · CVE-2026-43499 · CVE-2026-43501 · CVE-2026-43868 · CVE-2026-43870 · CVE-2026-4437 · CVE-2026-4438 · CVE-2026-45852 · CVE-2026-46054 · CVE-2026-46086 · CVE-2026-46116 · CVE-2026-46173 · CVE-2026-46181 · CVE-2026-46242 · CVE-2026-46259 · CVE-2026-46300 · CVE-2026-46331 · CVE-2026-46333 · CVE-2026-46917 · CVE-2026-46968 · CVE-2026-47010 · CVE-2026-47021 · CVE-2026-47027 · CVE-2026-47059 · CVE-2026-47063 · CVE-2026-48144 · CVE-2026-48145 · CVE-2026-5260 · CVE-2026-52923 · CVE-2026-52991 · CVE-2026-53006 · CVE-2026-53009 · CVE-2026-53131 · CVE-2026-53189 · CVE-2026-53264 · CVE-2026-53266 · CVE-2026-5419 · CVE-2026-5450 · CVE-2026-55602 · CVE-2026-55603 · CVE-2026-55968 · CVE-2026-55970 · CVE-2026-58010 · CVE-2026-58011 · CVE-2026-58012 · CVE-2026-58013 · CVE-2026-58014 · CVE-2026-58015 · CVE-2026-58016 · CVE-2026-58662 · CVE-2026-59879 · CVE-2026-59880 · CVE-2026-60147 · CVE-2026-60589 · CVE-2026-61308 · CVE-2026-63913 · CVE-2026-63952 · CVE-2026-64017 · CVE-2026-64530 · CVE-2026-64560 · CVE-2026-70906 · CVE-2026-70907 · CVE-2026-74581 · CVE-2026-82417 · CVE-2026-82562 · CVE-2026-83605 · CVE-2026-83607 · CVE-2026-83608 · CVE-2026-83613 · CVE-2026-83614 · CVE-2026-83615 · CVE-2026-83616 · CVE-2026-83619

NCSC-2026-0431: Kwetsbaarheden verholpen in IBM DataPower Gateway en onderliggende componenten

CVE-2023-53781 · CVE-2025-14087 · CVE-2025-14512 · CVE-2025-21858 · CVE-2025-22105 · CVE-2025-37980 · CVE-2025-38015 · CVE-2025-38097 · CVE-2025-38180 · CVE-2025-38400 · CVE-2025-38405 · CVE-2025-38441 · CVE-2025-38470 · CVE-2025-38653 · CVE-2025-39766 · CVE-2025-39797 · CVE-2025-39866 · CVE-2025-40134 · CVE-2025-48431 · CVE-2025-5278 · CVE-2025-68183 · CVE-2025-68211 · CVE-2025-68214 · CVE-2025-68347 · CVE-2025-68366 · CVE-2025-68724 · CVE-2025-71066 · CVE-2025-71089 · CVE-2026-12143 · CVE-2026-13257 · CVE-2026-13258 · CVE-2026-13757 · CVE-2026-14269 · CVE-2026-14273 · CVE-2026-14496 · CVE-2026-14497 · CVE-2026-14502 · CVE-2026-14507 · CVE-2026-14508 · CVE-2026-14509 · CVE-2026-14888 · CVE-2026-14905 · CVE-2026-14988 · CVE-2026-14990 · CVE-2026-14991 · CVE-2026-14992 · CVE-2026-14999 · CVE-2026-15588 · CVE-2026-15762 · CVE-2026-15781 · CVE-2026-15784 · CVE-2026-15819 · CVE-2026-15822 · CVE-2026-15824 · CVE-2026-16111 · CVE-2026-16159 · CVE-2026-16161 · CVE-2026-16163 · CVE-2026-16164 · CVE-2026-16165 · CVE-2026-16167 · CVE-2026-16169 · CVE-2026-16170 · CVE-2026-16176 · CVE-2026-16177 · CVE-2026-16178 · CVE-2026-16179 · CVE-2026-16181 · CVE-2026-16182 · CVE-2026-16340 · CVE-2026-16439 · CVE-2026-16440 · CVE-2026-16441 · CVE-2026-2100 · CVE-2026-22979 · CVE-2026-22984 · CVE-2026-22990 · CVE-2026-23002 · CVE-2026-23060 · CVE-2026-23110 · CVE-2026-23204 · CVE-2026-23209 · CVE-2026-23216 · CVE-2026-23243 · CVE-2026-23270 · CVE-2026-23392 · CVE-2026-23455 · CVE-2026-2391 · CVE-2026-31411 · CVE-2026-31419 · CVE-2026-31488 · CVE-2026-31508 · CVE-2026-31532 · CVE-2026-31581 · CVE-2026-31607 · CVE-2026-31613 · CVE-2026-31669 · CVE-2026-31677 · CVE-2026-31684 · CVE-2026-31685 · CVE-2026-33845 · CVE-2026-33846 · CVE-2026-3832 · CVE-2026-3833 · CVE-2026-4046 · CVE-2026-41254 · CVE-2026-41602 · CVE-2026-41606 · CVE-2026-41607 · CVE-2026-42009 · CVE-2026-42010 · CVE-2026-42011 · CVE-2026-42012 · CVE-2026-42013 · CVE-2026-42014 · CVE-2026-42015 · CVE-2026-43027 · CVE-2026-43037 · CVE-2026-43038 · CVE-2026-43056 · CVE-2026-43074 · CVE-2026-43116 · CVE-2026-43125 · CVE-2026-43163 · CVE-2026-43190 · CVE-2026-43198 · CVE-2026-43260 · CVE-2026-43284 · CVE-2026-43303 · CVE-2026-43329 · CVE-2026-43499 · CVE-2026-43501 · CVE-2026-43868 · CVE-2026-43870 · CVE-2026-4437 · CVE-2026-4438 · CVE-2026-45852 · CVE-2026-46054 · CVE-2026-46086 · CVE-2026-46116 · CVE-2026-46173 · CVE-2026-46181 · CVE-2026-46242 · CVE-2026-46259 · CVE-2026-46300 · CVE-2026-46331 · CVE-2026-46333 · CVE-2026-46917 · CVE-2026-46968 · CVE-2026-47010 · CVE-2026-47021 · CVE-2026-47027 · CVE-2026-47059 · CVE-2026-47063 · CVE-2026-48144 · CVE-2026-48145 · CVE-2026-5260 · CVE-2026-52923 · CVE-2026-52991 · CVE-2026-53006 · CVE-2026-53009 · CVE-2026-53131 · CVE-2026-53189 · CVE-2026-53264 · CVE-2026-53266 · CVE-2026-5419 · CVE-2026-5450 · CVE-2026-55602 · CVE-2026-55603 · CVE-2026-55968 · CVE-2026-55970 · CVE-2026-58010 · CVE-2026-58011 · CVE-2026-58012 · CVE-2026-58013 · CVE-2026-58014 · CVE-2026-58015 · CVE-2026-58016 · CVE-2026-58662 · CVE-2026-59879 · CVE-2026-59880 · CVE-2026-60147 · CVE-2026-60589 · CVE-2026-61308 · CVE-2026-63913 · CVE-2026-63952 · CVE-2026-64017 · CVE-2026-64530 · CVE-2026-64560 · CVE-2026-70906 · CVE-2026-70907 · CVE-2026-74581 · CVE-2026-82417 · CVE-2026-82562 · CVE-2026-83605 · CVE-2026-83607 · CVE-2026-83608 · CVE-2026-83613 · CVE-2026-83614 · CVE-2026-83615 · CVE-2026-83616 · CVE-2026-83619

RHSA-2026:62544: Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update

CVE-2026-82417 · CVE-2026-82562

WID-SEC-W-2026-3596: IBM App Connect Enterprise: Mehrere Schwachstellen

CVE-2022-35948 · CVE-2026-13149 · CVE-2026-14257 · CVE-2026-15157 · CVE-2026-1527 · CVE-2026-16728 · CVE-2026-16729 · CVE-2026-18149 · CVE-2026-18540 · CVE-2026-19534 · CVE-2026-2391 · CVE-2026-45820 · CVE-2026-54272 · CVE-2026-63670 · CVE-2026-67213 · CVE-2026-67214 · CVE-2026-69152 · CVE-2026-69192 · CVE-2026-69198 · CVE-2026-73566 · CVE-2026-73646 · CVE-2026-77037 · CVE-2026-77063 · CVE-2026-77078 · CVE-2026-82333 · CVE-2026-82417 · CVE-2026-82562 · CVE-2026-83605 · CVE-2026-83606 · CVE-2026-83607 · CVE-2026-83608 · CVE-2026-83609 · CVE-2026-83610 · CVE-2026-83611 · CVE-2026-83612 · CVE-2026-83613 · CVE-2026-83614 · CVE-2026-83615 · CVE-2026-83616 · CVE-2026-83618 · CVE-2026-83619 · CVE-2026-84292 · CVE-2026-84371 · CVE-2026-84375 · CVE-2026-84890 · CVE-2026-84933 · CVE-2026-84947 · CVE-2026-84961 · CVE-2026-85008 · CVE-2026-85014 · CVE-2026-85024 · CVE-2026-85152

RHSA-2026:68754: Red Hat Security Advisory: Red Hat OpenShift Dev Spaces 3.30.1 Release.

CVE-2026-4800 · CVE-2026-45623 · CVE-2026-45819 · CVE-2026-47219 · CVE-2026-48801 · CVE-2026-54272 · CVE-2026-55831 · CVE-2026-55833 · CVE-2026-56745 · CVE-2026-56746 · CVE-2026-56819 · CVE-2026-59887 · CVE-2026-59899 · CVE-2026-67213 · CVE-2026-67312 · CVE-2026-67313 · CVE-2026-67314 · CVE-2026-67320 · CVE-2026-67321 · CVE-2026-69152 · CVE-2026-69153 · CVE-2026-69192 · CVE-2026-71436 · CVE-2026-73086 · CVE-2026-73088 · CVE-2026-73089 · CVE-2026-73508 · CVE-2026-73566 · CVE-2026-73646 · CVE-2026-75899 · CVE-2026-75931 · CVE-2026-75975 · CVE-2026-76172 · CVE-2026-82562 · CVE-2026-84292 · CVE-2026-84375 · CVE-2026-84394

RHSA-2026:60866: Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update

CVE-2026-73501 · CVE-2026-75899 · CVE-2026-75931 · CVE-2026-75975 · CVE-2026-76172 · CVE-2026-82562

RHSA-2026:90321: Red Hat Security Advisory: Red Hat OpenShift Dev Spaces 3.31.0 Release.

CVE-2023-54404 · CVE-2025-62718 · CVE-2026-8643 · CVE-2026-9496 · CVE-2026-12185 · CVE-2026-13697 · CVE-2026-14682 · CVE-2026-15076 · CVE-2026-16308 · CVE-2026-17106 · CVE-2026-18427 · CVE-2026-19203 · CVE-2026-19534 · CVE-2026-39820 · CVE-2026-41178 · CVE-2026-41707 · CVE-2026-42499 · CVE-2026-42502 · CVE-2026-45416 · CVE-2026-47884 · CVE-2026-47886 · CVE-2026-47888 · CVE-2026-47890 · CVE-2026-47892 · CVE-2026-50010 · CVE-2026-55831 · CVE-2026-55833 · CVE-2026-55851 · CVE-2026-56745 · CVE-2026-56746 · CVE-2026-56819 · CVE-2026-56852 · CVE-2026-56854 · CVE-2026-58062 · CVE-2026-59280 · CVE-2026-59282 · CVE-2026-59283 · CVE-2026-59296 · CVE-2026-59313 · CVE-2026-59323 · CVE-2026-59651 · CVE-2026-59887 · CVE-2026-59899 · CVE-2026-59901 · CVE-2026-62243 · CVE-2026-64607 · CVE-2026-67213 · CVE-2026-67312 · CVE-2026-67313 · CVE-2026-67314 · CVE-2026-67320 · CVE-2026-67321 · CVE-2026-68494 · CVE-2026-68497 · CVE-2026-69152 · CVE-2026-69192 · CVE-2026-71290 · CVE-2026-71324 · CVE-2026-71325 · CVE-2026-71327 · CVE-2026-73500 · CVE-2026-73508 · CVE-2026-74835 · CVE-2026-75838 · CVE-2026-75899 · CVE-2026-75931 · CVE-2026-76169 · CVE-2026-81521 · CVE-2026-82417 · CVE-2026-82562 · CVE-2026-84292 · CVE-2026-84375 · CVE-2026-84394 · CVE-2026-84428 · CVE-2026-84445 · CVE-2026-84469 · CVE-2026-84504 · CVE-2026-84961 · CVE-2026-85062 · CVE-2026-85124 · CVE-2026-85152 · CVE-2026-85595 · CVE-2026-85597 · CVE-2026-86063 · CVE-2026-87743 · CVE-2026-88004 · CVE-2026-88007 · CVE-2026-88008 · CVE-2026-88009 · CVE-2026-88011 · CVE-2026-88012 · CVE-2026-88031 · CVE-2026-88878 · CVE-2026-88879 · CVE-2026-90711 · CVE-2026-93749 · CVE-2026-100655 · CVE-2026-100656 · CVE-2026-100666 · CVE-2026-101916 · CVE-2026-102925 · CVE-2026-102930 · CVE-2026-103435 · CVE-2026-109618 · CVE-2026-109619

Source published
Aug 29, 2026, 11:58:31 PM (timezone not stated)
Source modified
Aug 31, 2026, 5:04:14 PM (timezone not stated)
Saved here
13 Nov 2026 18:01:42 UTC
Source terms
ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

Source: euvd · ENISA EUVD · source terms and attribution apply. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

EUVD CVSS 4.0 · 6.3 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

nvd · CVE-2026-82562

Published

### Summary

### 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 ```js var qs = require('qs'); var options = { comma: true, arrayLimit: 3, throwOnLimitExceeded: true }; qs.parse('a=1,2,3,4', options); // RangeError: Array limit exceeded. Only 3 elements allowed in an array. qs.parse('a[]=1,2,3,4', options); // { a: [ [ '1', '2', '3', '4' ] ] } (no throw) qs.parse('a[]=' + '1,'.repeat(1000000) + '1', { comma: true, arrayLimit: 20, throwOnLimitExceeded: true }); // no throw; a 1,000,001-element inner array is allocated ``` #### 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.

Additional publisher context

NVD analysis and CPE criteria are source context, not proof that a package or your environment is affected. Complete affected data, logical configurations and SSVC are retained in the original JSON.

Source analysis status: Awaiting Analysis

Weakness classifications: CWE-770

Original publisher date fields

published: 2026-08-30T01:20:32.820

lastModified: 2026-09-03T18:00:36.970

Source published
30 Aug 2026 01:20:32 UTC
Source modified
3 Sep 2026 18:00:36 UTC
Saved here
25 Oct 2026 16:19:10 UTC
Source terms
NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

Source: nvd · NIST NVD usage terms; underlying source attribution retained. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 4.0 · 7ffcee3d-2c14-4c3e-b844-86c6a321a158 · Secondary · 6.3 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

CVSS 3.1 · 7ffcee3d-2c14-4c3e-b844-86c6a321a158 · Secondary · 3.7 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

osv · GHSA-x5fp-wj9c-mxmx

Published

qs array-limit bypass via bracket-key comma parsing

### 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.

Source published
2 Sep 2026 14:46:57 UTC
Source modified
10 Sep 2026 03:50:54 UTC
Saved here
24 Oct 2026 13:17:17 UTC
Source terms
GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

Source: osv · GitHub Advisory Database · CC-BY-4.0. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS_V3 · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

CVSS_V4 · CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Publisher rating · MODERATE

ChangeIntel

An IT change radar: releases, security, known issues, retirements, documentation changes, and service status from public sources. Every item links to supporting evidence; dates and statuses can change after they are read.

Sources read 15 Nov 11:08 UTC · 256 of 275 readable · 252 fully read · documentation 469/469 current

No accounts or analytics; your preferences stay in your browser. Information, not advice. ChangeIntel is an independent tool and is not affiliated with or endorsed by Microsoft, Apple, Google, Broadcom (VMware), Jamf, Oracle, Mozilla, or any other vendor it covers. Product names are trademarks of their owners.