CVE-2026-32316: jq JSON Processor Buffer Overflow Flaw

CVE-2026-32316 Overview

CVE-2026-32316 is an integer overflow vulnerability in jq, a widely-used command-line JSON processor. The vulnerability exists within the jvp_string_append() and jvp_string_copy_replace_bad functions through version 1.8.1. When concatenating strings with a combined length exceeding 2^31 bytes, a 32-bit unsigned integer overflow occurs in the buffer allocation size calculation, resulting in a drastically undersized heap buffer. Subsequent memory copy operations then write the full string data into this undersized buffer, causing a heap buffer overflow.

This vulnerability is classified as CWE-190 (Integer Overflow) leading to CWE-122 (Heap-based Buffer Overflow), representing a serious memory corruption flaw that can be triggered remotely.

Critical Impact

Any system evaluating untrusted jq queries is affected. An attacker can crash the process or potentially achieve further exploitation through heap corruption by crafting queries that produce extremely large strings.

Affected Products

• jq versions through 1.8.1
• Systems processing untrusted jq queries
• Applications using jq as a library component

Discovery Timeline

• 2026-04-13 - CVE CVE-2026-32316 published to NVD
• 2026-04-13 - Last updated in NVD database

Technical Details for CVE-2026-32316

Vulnerability Analysis

The vulnerability stems from improper handling of string length calculations in jq's internal string manipulation functions. The jvp_string_append() and jvp_string_copy_replace_bad functions use a 32-bit unsigned integer (uint32_t) to calculate the maximum buffer length required when processing strings. This calculation includes a worst-case multiplier of 3 (to account for potential UTF-8 replacement characters) plus 1 byte.

When an attacker supplies input that causes the calculated buffer size to exceed the maximum value representable in 32 bits (2^31 bytes), the integer overflows and wraps around to a much smaller value. The subsequent heap allocation creates a buffer far too small to hold the actual data. When the string data is copied into this undersized buffer, it overwrites adjacent heap memory, leading to heap corruption.

The root cause is the absence of string size bounds checking. Unlike arrays and objects in jq which already have size limits implemented, strings lacked equivalent validation, creating an exploitable attack surface.

Root Cause

The vulnerability originates from using a 32-bit unsigned integer type (uint32_t) for buffer size calculations without validating that the result doesn't overflow. The calculation length * 3 + 1 can produce a value exceeding INT_MAX when processing very large input strings. The fix upgrades the calculation to use a 64-bit integer (uint64_t) and adds explicit bounds checking to reject strings that would exceed safe limits.

Attack Vector

The attack vector is network-based, requiring no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Crafting malicious jq queries that generate extremely large strings through concatenation operations
2. Submitting these queries to any service that processes untrusted jq input
3. Triggering the integer overflow during string buffer allocation
4. Exploiting the resulting heap buffer overflow for denial of service or potential code execution

The following patch shows how the vulnerability was addressed:

   const char* end = data + length;
   const char* i = data;
 
-  uint32_t maxlength = length * 3 + 1; // worst case: all bad bytes, each becomes a 3-byte U+FFFD
+  // worst case: all bad bytes, each becomes a 3-byte U+FFFD
+  uint64_t maxlength = (uint64_t)length * 3 + 1;
+  if (maxlength >= INT_MAX) {
+    return jv_invalid_with_msg(jv_string("String too long"));
+  }
+
   jvp_string* s = jvp_string_alloc(maxlength);
   char* out = s->data;
   int c = 0;

Source: GitHub Commit Details

Detection Methods for CVE-2026-32316

Indicators of Compromise

• Abnormal jq process crashes with heap corruption errors or segmentation faults
• Memory allocation failures in jq processes handling large string inputs
• Unusual jq queries containing repetitive string concatenation patterns designed to produce multi-gigabyte outputs
• System logs indicating out-of-memory conditions during jq query processing

Detection Strategies

• Monitor jq processes for abnormal termination signals (SIGSEGV, SIGABRT)
• Implement input validation to reject jq queries that could produce excessively large string outputs
• Deploy runtime memory protection mechanisms such as Address Sanitizer (ASan) in development environments
• Review application logs for repeated jq failures when processing specific input patterns

Monitoring Recommendations

• Implement memory usage monitoring for processes invoking jq
• Set up alerts for jq process crashes in production environments
• Monitor for unusually large string operations in jq query patterns
• Track input sizes to jq processing endpoints to detect potential exploitation attempts

How to Mitigate CVE-2026-32316

Immediate Actions Required

• Update jq to the patched version that includes commit e47e56d226519635768e6aab2f38f0ab037c09e5
• Audit systems to identify all instances of jq processing untrusted input
• Implement input validation to limit the size of data processed by jq
• Consider restricting jq functionality in environments handling untrusted queries

Patch Information

The vulnerability has been addressed in commit e47e56d226519635768e6aab2f38f0ab037c09e5. The fix upgrades the buffer size calculation from uint32_t to uint64_t and adds explicit bounds checking to return an error when the calculated string length would exceed INT_MAX. Organizations should update to a jq version containing this commit.

For detailed patch information, refer to the GitHub Security Advisory GHSA-q3h9-m34w-h76f.

Workarounds

• Implement input size limits at the application layer before passing data to jq
• Sandbox jq processes using containerization or process isolation mechanisms
• Avoid processing untrusted jq queries in production environments until patching is complete
• Deploy memory limits (ulimit) on processes that invoke jq to contain potential exploitation

# Example: Limit jq process memory to 2GB to mitigate exploitation impact
ulimit -v 2097152
jq '.data' input.json