CVE-2025-15284

What it actually does

The flaw is an improper input validation issue in the qs query-string parsing library before version 6.14.1. When applications parse query strings or URL-encoded request bodies using bracket array notation such as a[]=1&a[]=2, the arrayLimit option is not enforced, even though it is enforced for indexed notation such as a[0]=1&a[1]=2. This can allow a request to create arrays larger than the application intended. With the default parameterLimit of 1000, practical denial-of-service impact is limited because each bracketed array element still consumes a parameter slot; risk is higher for applications that explicitly raise parameterLimit to a large value or parse very large attacker-controlled query strings or form bodies.

Why it matters to the business

The most likely consequence is reduced service availability or increased CPU and memory consumption in web applications that use vulnerable qs versions and permissive parser settings. For most default configurations, the operational risk is low because qs already limits the total number of parameters, and the CVSS and EPSS values indicate low severity and low near-term exploitation likelihood. Organizations with high-traffic internet-facing Node.js services, API gateways, or middleware that increased parser parameter limits should still patch to avoid request-driven resource exhaustion and unexpected parsing behavior.

How an attack unfolds

An unauthenticated remote attacker sends HTTP requests containing a large number of repeated bracket-notation parameters, for example many instances of a[]=value, to an endpoint that parses query strings or application/x-www-form-urlencoded request bodies with a vulnerable qs version. If the application relies on arrayLimit to restrict array size, qs incorrectly applies that limit only to indexed arrays and not to bracket arrays. In configurations where parameterLimit has been raised significantly, the parser may allocate and combine a large array despite the intended arrayLimit, consuming CPU and memory and potentially slowing or disrupting the application. There is no indication from the provided intelligence that this issue is in CISA KEV, used in ransomware campaigns, or associated with named threat actors.

How to fix it

Upgrade qs to version 6.14.1 or later. For source builds tracking ljharb/qs directly, ensure the fix commit 3086902ecf7f088d0d1803887643ac6c03d415b9 or a later revision is present. For Debian-packaged references in the supplied data, use the vendor-fixed package version listed as 4.1-1 for Debian 11, Debian 12, and Debian 13 where applicable. As defense in depth, keep qs parameterLimit at the default or another low, justified value; set explicit request body and URL length limits in the web framework, reverse proxy, and load balancer; reject unusually large application/x-www-form-urlencoded bodies; and apply rate limiting to endpoints that parse user-controlled parameters.

How to confirm the fix worked

Confirm dependency resolution shows qs version 6.14.1 or later, or that the patched upstream commit is included for vendored copies. Use package-lock.json, npm ls qs, yarn why qs, pnpm why qs, SBOM output, container image scans, and source-code searches to find direct and transitive qs usage. Validate runtime behavior with a safe test: parse a query such as a[]=1&a[]=2&a[]=3&a[]=4&a[]=5&a[]=6 using a low arrayLimit and verify bracket notation is constrained consistently with indexed notation. Also verify that application, proxy, and framework request-size limits are active and that large query strings or URL-encoded bodies are rejected before they can consume significant application resources.

Typical attack path

1. Identify an internet-facing endpoint that accepts query-string parameters or URL-encoded request bodies.
2. Send requests containing many repeated bracket-notation array parameters such as a[]=1&a[]=2&a[]=3.
3. Target applications using qs before 6.14.1, especially where parser parameterLimit has been increased above the default.
4. Cause the application to parse more array elements than intended by arrayLimit.
5. Repeat or parallelize requests to increase CPU, memory, request latency, or worker exhaustion impact.

How to detect it

Review HTTP access logs, WAF logs, reverse proxy logs, application logs, APM traces, and Node.js process telemetry for requests containing unusually long query strings or URL-encoded bodies with many repeated bracket-notation parameters. Focus on patterns such as repeated a[]=, ids[]=, tags[]=, filter[]=, or other parameter names appearing hundreds or thousands of times in one request. Correlate these requests with elevated response times, 408/429/500/502/503/504 responses, Node.js heap growth, out-of-memory events, process restarts, high garbage-collection time, or worker saturation. If body logging is not enabled, use WAF/request metadata such as query length, request body size, parameter count, and content type application/x-www-form-urlencoded. There are no known actor-specific indicators from the supplied intelligence; detection should be behavior-based around resource-exhaustion attempts using bracket array notation.

• a[]=
• %5B%5D=
• application/x-www-form-urlencoded
• parameterLimit
• arrayLimit
• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed
• ENOMEM
• out of memory
• Request-URI Too Long
• 414 Request-URI Too Long
• 413 Payload Too Large
• upstream timed out
• worker process exited
• a[]=1&a[]=2&a[]=3&a[]=4&a[]=5&a[]=6

What your security team should do

• Inventory all applications and containers that include qs before 6.14.1, including transitive dependencies in Express-compatible middleware and other Node.js web stacks.
• Prioritize patching internet-facing services and any service that increased qs parameterLimit or accepts large URL-encoded request bodies.
• Upgrade to qs 6.14.1 or later and regenerate lockfiles so transitive dependency resolution cannot retain a vulnerable version.
• Add or verify request body size, URL length, parameter count, and per-IP rate limits at the edge and application layer.
• Search recent HTTP access logs and application performance telemetry for spikes in long query strings, repeated bracket-notation parameters, 4xx/5xx responses, memory pressure, garbage collection spikes, or request latency anomalies.
• Because this is not KEV-listed, has no known exploit maturity in the supplied data, and has low EPSS, handle as routine patching unless local exposure includes permissive parser settings on high-value internet-facing services.