CVE-2026-82562 Affecting kubeflow-centraldashboard package, versions <2.0.0-r2

Note: Versions mentioned in the description apply only to the upstream kubeflow-centraldashboard package and not the kubeflow-centraldashboard package as distributed by Wolfi. See How to fix? for Wolfi relevant fixed versions and status.

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

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.

• https://github.com/ljharb/qs/commit/8859c37470e11b42b547b275e4e9bd0bc8cc5464
• https://github.com/ljharb/qs/security/advisories/GHSA-w7fw-mjwx-w883
• https://github.com/ljharb/qs/security/advisories/GHSA-x5fp-wj9c-mxmx