CVE-2026-32316: 
NixOS vulnerability analysis and mitigation

CVE-2026-32316 is an integer overflow vulnerability in jq, the popular command-line JSON processor, affecting all versions through 1.8.1. The flaw exists in the jvp_string_append() and jvp_string_copy_replace_bad() functions in src/jv.c, where concatenating strings with a combined length exceeding 2^31 bytes causes a 32-bit unsigned integer overflow in the buffer allocation size calculation, resulting in a heap buffer overflow. It was published on April 13, 2026, with a fix committed the same day. The vulnerability carries a CVSS v3.1 base score of 8.2 (High) per the GitHub Security Advisory, or 7.5 (High) per NVD (GitHub Advisory, Feedly).

The root cause is a missing bounds check on string sizes in two internal functions (CWE-190: Integer Overflow leading to CWE-122: Heap-based Buffer Overflow). In jvp_string_append(), the allocation size is computed as (currlen + len) * 2 using uint32_t arithmetic; when currlen + len >= 2^31, the multiplication overflows, wrapping allocsz to a small value (potentially 0, clamped to 32), after which a memcpy writes gigabytes of data into the undersized heap buffer. In jvp_string_copy_replace_bad(), the worst-case output buffer size length * 3 + 1 similarly overflows uint32_t when length is large enough, producing a tiny allocation followed by a massive write. Unlike arrays and objects in jq, strings had no equivalent size limit. The fix (commit e47e56d) adds overflow checks using uint64_t arithmetic and returns an error for strings exceeding INT_MAX in length (GitHub Advisory, Fix Commit).

Successful exploitation allows an unauthenticated attacker to crash the jq process (denial of service) by crafting a jq query that produces strings exceeding 2^31 bytes, or by supplying a sufficiently large JSON input to a fixed query that triggers the overflow. Beyond denial of service, heap corruption resulting from the out-of-bounds write may enable further exploitation depending on the memory allocator and runtime environment, though no confirmed remote code execution has been demonstrated. Any system or pipeline that evaluates untrusted jq queries — including web services, CI/CD pipelines, and data processing tools — is at risk (GitHub Advisory).

Public proof-of-concept commands are available in the official GitHub Security Advisory and can be run directly without any special tooling or privileges. The EPSS score is approximately 0.04%, reflecting low current exploitation probability. There is no evidence of in-the-wild exploitation or CISA KEV catalog inclusion as of the time of this report. No threat actor attribution has been identified (GitHub Advisory, Feedly).

1. Identify target: Locate a system or service that passes untrusted user input as a jq query or as JSON data to a jq query that performs string concatenation or base64 decoding operations.
2. Craft overflow via string concatenation: Construct a jq query that concatenates strings whose combined length exceeds 2^31 bytes, for example:

   jq -n '("x" * 2147483646) + "xx" | length'

   This sets currlen = 2147483646 and len = 2, causing (currlen + len) * 2 to overflow to 0, clamped to 32, then memcpy writes ~2 GB into a 32-byte buffer.
3. Craft overflow via base64 decoding: Alternatively, trigger the jvp_string_copy_replace_bad path using invalid UTF-8 produced by base64 decoding:

   jq -n '"////" * 477218589 | @base64d | length'

   This produces ~1.4 GB of 0xFF bytes; the replacement buffer size calculation overflows, allocating only 6 bytes while writing ~4.3 GB.
4. Achieve denial of service or heap corruption: Submit the crafted query or input to the target system. The jq process crashes due to heap buffer overflow; depending on the allocator, heap metadata corruption may be leveraged for further exploitation (GitHub Advisory).

• Process: Unexpected crashes or segmentation faults in the jq process, particularly when processing user-supplied queries or large JSON inputs.
• Logs: Application or system logs showing jq process termination with signals such as SIGSEGV or SIGABRT; error messages containing "String too long" (present in patched versions, indicating attempted exploitation against a patched system).
• Network: Unusually large JSON payloads or jq query strings submitted to APIs or services that invoke jq internally, especially those containing repeated string multiplication operators (* <large_number>) or @base64d filters on large inputs.
• File System: Core dump files generated by jq process crashes in the working directory or system core dump location.

The fix is available in commit e47e56d226519635768e6aab2f38f0ab037c09e5 in the jq repository; users should update to any jq release that includes this commit (post-1.8.1). Ubuntu has issued security notices USN-8202-1, USN-8202-2, and USN-8202-3 with patched packages, and Amazon Linux 2023 has released ALAS2023-2026-1815. If immediate patching is not possible, avoid evaluating untrusted or user-supplied jq queries, implement input validation to restrict query complexity and string sizes, and consider running jq in a sandboxed environment to limit the blast radius of process crashes (GitHub Advisory, Fix Commit, Ubuntu USN-8202-2).

The vulnerability was disclosed via the jq GitHub Security Advisory by maintainer itchyny on April 12–13, 2026, and was also reported to the oss-security mailing list. Ubuntu issued multiple security notices (USN-8202-1 through USN-8202-3) and Microsoft's MSRC acknowledged the CVE. Community discussion appeared on Bluesky and security blogs, with some coverage noting the practical difficulty of triggering the overflow (requiring multi-gigabyte string operations) as a mitigating factor in real-world exploitation risk (oss-security, Ubuntu USN-8202-2, MSRC).