CVE-2026-8723

What it actually does

This flaw is a denial-of-service condition in the Node.js qs package affecting versions >=6.11.1 and <6.15.2. When application code calls qs.stringify with the non-default options arrayFormat: 'comma' and encodeValuesOnly: true, and the array being serialized contains null or undefined, qs attempts to encode the nullish value before null-handling logic runs. The encoder reads the value's length property without a null guard, causing a synchronous TypeError. In most HTTP frameworks, this results in the affected request returning a 500 error; in less protected contexts such as background jobs, startup code, stream pipelines, or custom handlers without an error boundary, the exception may interrupt the task or process flow.

Why it matters to the business

The main risk is application instability or degraded availability when vulnerable serialization paths process attacker-controlled or malformed data. Public APIs that accept JSON arrays and later serialize them into query strings are the most exposed. Successful exploitation typically causes request failures rather than full system compromise, but repeated triggering can create elevated error rates, disrupt integrations, degrade user experience, and increase operational load. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no reported exploit maturity in the provided data, so remediation should be prioritized according to exposure of affected code paths rather than treated as an emergency internet-wide compromise risk.

How an attack unfolds

An attacker first identifies an application endpoint or workflow that accepts user-controlled structured data, especially JSON, and later passes an array from that input into qs.stringify. Exploitation requires the application to use qs.stringify with both arrayFormat: 'comma' and encodeValuesOnly: true. The attacker submits an array containing a literal null value, or otherwise influences application logic to create an array containing null or undefined. When the application attempts to serialize that array, qs enters the comma-format encode-values-only branch, maps the raw encoder over the array, and throws a TypeError while attempting to read length from the nullish element. In a typical Express, Fastify, Koa, hapi, or similar request handler with standard error handling, the attacker receives a 500 response and the process continues serving later requests. If the same vulnerable call occurs outside a protected request boundary, the synchronous exception can disrupt a background job, initialization path, pipeline, or custom process flow.

How to fix it

Upgrade the qs package to version 6.15.2 or later. The affected range is >=6.11.1 and <6.15.2; versions before 6.11.1 are not affected by this specific code path, but upgrading to the fixed current release is preferred over downgrading. Regenerate lockfiles and redeploy all applications, services, serverless functions, build tools, and background workers that bundle or depend on the vulnerable qs version. If immediate upgrade is not possible, avoid calling qs.stringify with both arrayFormat: 'comma' and encodeValuesOnly: true on arrays derived from untrusted input, or sanitize arrays before serialization by removing, replacing, or explicitly handling null and undefined elements. Ensure request handlers and background workers have robust exception handling so synchronous serialization errors cannot terminate critical processing.

How to confirm the fix worked

Confirm dependency resolution shows qs version 6.15.2 or later wherever the package is installed or bundled. For npm-based projects, use commands such as npm ls qs, npm audit, yarn why qs, pnpm why qs, or software composition analysis tooling to find direct and transitive instances. Validate that lockfiles no longer resolve qs to versions >=6.11.1 and <6.15.2. Add or run a regression test that calls qs.stringify({ a: [null, 'b'] }, { arrayFormat: 'comma', encodeValuesOnly: true }) and qs.stringify({ a: [undefined, 'b'] }, { arrayFormat: 'comma', encodeValuesOnly: true }); fixed versions should not throw a TypeError. In deployed environments, monitor application logs and APM traces after rollout to verify the related TypeError no longer appears and that 500-rate spikes associated with affected endpoints subside.

Typical attack path

1. Find an application endpoint or workflow that accepts structured input such as JSON arrays.
2. Determine or infer that the application serializes that data using qs.stringify with arrayFormat: 'comma' and encodeValuesOnly: true.
3. Submit input containing an array with a null value, or trigger application logic that produces an array containing null or undefined.
4. Cause the vulnerable qs.stringify call to execute on the crafted array.
5. Trigger a synchronous TypeError in qs during value encoding.
6. Observe a 500 response, failed job, aborted workflow, or other availability degradation.
7. Repeat the request or workflow to sustain elevated error rates if the endpoint remains exposed.

How to detect it

To assess prior exploitation or triggering, search application logs, centralized logging platforms, APM error traces, serverless logs, container stdout/stderr, process manager logs, and reverse proxy metrics for synchronous TypeError events from qs followed by HTTP 500 responses or failed background jobs. Focus on time windows after the vulnerable package version was deployed and on endpoints that accept JSON arrays or perform outbound query-string construction. Useful artifacts include stack traces referencing qs lib/utils.js encode, qs lib/stringify.js, Object.maybeMap, and error messages indicating that length was read from null or undefined. Correlate matching exceptions with request bodies containing arrays with null values where request-body logging is available and policy-compliant. Also look for repeated requests from the same source that produce consistent 500 responses without corresponding application-state changes, which may indicate deliberate availability probing. Because exploitation generally causes an application error rather than code execution, indicators are primarily log and telemetry based rather than filesystem or host artifacts.

• TypeError: Cannot read properties of null (reading 'length')
• TypeError: Cannot read properties of undefined (reading 'length')
• Cannot read properties of null (reading 'length')
• Cannot read properties of undefined (reading 'length')
• at encode (lib/utils.js:195:13)
• lib/utils.js:195
• at Object.maybeMap (lib/utils.js:322:37)
• lib/utils.js:322
• at stringify (lib/stringify.js:145:25)
• lib/stringify.js:145
• arrayFormat: 'comma'
• encodeValuesOnly: true

What your security team should do

• Inventory all applications and packages that include qs, including transitive dependencies and bundled JavaScript artifacts.
• Prioritize remediation for internet-facing APIs, webhook receivers, integration gateways, and services that accept JSON arrays or construct query strings from user-controlled input.
• Upgrade qs to 6.15.2 or later and redeploy affected services; ensure lockfiles and container images are rebuilt so vulnerable copies are not retained.
• Add regression tests for qs.stringify with arrayFormat: 'comma', encodeValuesOnly: true, and arrays containing null or undefined.
• Review application code for unguarded serialization of user-controlled arrays and normalize nullish values before query-string generation where appropriate.
• Ensure web frameworks, workers, and pipeline code have error boundaries that convert synchronous exceptions into controlled failures rather than process termination.
• Create detections for the specific TypeError and stack frames associated with this bug, and investigate historical spikes in matching errors or unexplained 500 responses.
• Because EPSS is low and the issue is not KEV-listed, prioritize based on reachable vulnerable code paths rather than package presence alone.