CVE-2026-43894: Jqlang Jq Buffer Overflow Vulnerability

CVE-2026-43894 Overview

CVE-2026-43894 is an integer overflow vulnerability [CWE-190] in jq, a widely deployed command-line JSON processor maintained by jqlang. The flaw affects version 1.8.1 and earlier. When decNumberFromString parses a decimal literal containing INT_MAX-1 (2,147,483,646) digits, the D2U() macro overflows during signed integer arithmetic. The wrapped negative value bypasses the heap-allocation size check, forcing the function to fall back to a 30-byte stack buffer. The function then writes approximately 715 million 16-bit units (~1.4 GiB) of attacker-controlled data at an offset 1.43 GiB below the current stack frame, producing a high-impact memory corruption condition.

Critical Impact

A local attacker who can supply a crafted JSON input to jq can trigger out-of-bounds stack writes of attacker-controlled content, leading to process crash or potential memory corruption with high availability impact.

Affected Products

• jqlang jq version 1.8.1
• jqlang jq versions prior to 1.8.1
• Downstream Linux distributions and container images bundling vulnerable jq builds

Discovery Timeline

• 2026-05-11 - CVE-2026-43894 published to the National Vulnerability Database
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-43894

Vulnerability Analysis

The vulnerability resides in decNumberFromString, the routine jq uses to parse arbitrary-precision decimal literals from JSON input. The function relies on the D2U() macro to compute how many 16-bit storage units (decNumberUnit) are required to hold a parsed digit string. D2U() performs signed 32-bit arithmetic on the digit count without bounding the input length.

When the digit count approaches INT_MAX, the intermediate expression inside D2U() overflows and produces a negative value. The subsequent allocation-size check compares this wrapped value against the threshold for switching from a small fixed stack buffer to heap allocation. Because the wrapped value is negative, the check incorrectly selects the 30-byte on-stack decNumberUnit buffer.

The parser then proceeds to write all 715 million packed digit units into the undersized stack buffer. The computed write offset lands approximately 1.43 GiB below the current stack frame, corrupting arbitrary memory along that range. The content written is fully attacker-controlled because each 16-bit unit is packed with three decimal digits taken directly from the input literal.

Root Cause

The root cause is an unchecked signed integer overflow inside the D2U() size macro [CWE-190]. The code assumes digit counts remain small enough to avoid wrapping, an invariant that no input validation enforces. A length sanity check on the parsed digit string before invoking D2U() would have prevented the overflow.

Attack Vector

Exploitation requires local access and the ability to feed crafted input to a jq process. An attacker provides a JSON document containing a number literal with roughly 2.1 billion decimal digits. Any pipeline, script, CI job, or service that invokes jq on attacker-controlled JSON is reachable. The CVSS vector identifies the impact as availability-only at this time, consistent with a memory corruption that reliably crashes the process. Reliable arbitrary code execution would require additional primitives given the large fixed write offset.

The vulnerability mechanism is documented in the jq GitHub Security Advisory GHSA-5v7p-2r57-2g4g.

Detection Methods for CVE-2026-43894

Indicators of Compromise

• Unexpected jq process crashes, segmentation faults, or stack-smashing aborts on hosts that parse external JSON.
• JSON input files or streams containing decimal number literals with digit counts in the hundreds of millions or billions.
• jq invocations consuming abnormal amounts of memory or CPU shortly before termination.

Detection Strategies

• Inventory all hosts, containers, and CI runners with jq installed and identify versions at or below 1.8.1 using package manager queries such as jq --version, dpkg -l jq, or rpm -q jq.
• Scan ingestion pipelines that pipe untrusted JSON into jq and flag inputs whose raw size exceeds reasonable thresholds (for example, JSON payloads larger than a few megabytes that contain a single numeric token).
• Correlate process exit codes and core dumps for jq with the source of the JSON input to identify suspicious patterns.

Monitoring Recommendations

• Enable core dump collection and crash telemetry for shell environments and automation hosts that run jq.
• Alert on repeated abnormal terminations of jq across a fleet, which can indicate scanning or fuzzing activity.
• Track outbound and inbound JSON payload sizes in pipelines and reject inputs that exceed application-appropriate length limits before they reach jq.

How to Mitigate CVE-2026-43894

Immediate Actions Required

• Upgrade jq to a fixed release once jqlang publishes a patched version above 1.8.1 across all servers, workstations, container images, and CI runners.
• Audit shell scripts, automation jobs, and services that pass untrusted JSON to jq and place hard size limits on input.
• Rebuild and redeploy container images that pin vulnerable jq versions in their base layers.

Patch Information

Reference the jq Security Advisory GHSA-5v7p-2r57-2g4g for the authoritative list of fixed versions and patch commits. Distribution maintainers typically publish backported builds shortly after upstream releases; consult vendor security trackers for Debian, Ubuntu, Red Hat, SUSE, and Alpine.

Workarounds

• Reject or truncate JSON inputs larger than the maximum size your application legitimately requires before invoking jq.
• Run jq under a resource-limited sandbox using ulimit -v or systemd MemoryMax= to contain the out-of-bounds write impact to a single process.
• Where feasible, replace jq with a JSON parser whose numeric handling is bounded for paths that process untrusted input.

# Configuration example: cap input size and constrain jq resources
MAX_BYTES=10485760  # 10 MiB ceiling for untrusted JSON
if [ "$(wc -c < "$INPUT")" -gt "$MAX_BYTES" ]; then
  echo "Input exceeds size limit" >&2
  exit 1
fi

# Run jq with restricted address space and CPU time
ulimit -v 524288   # 512 MiB virtual memory cap
ulimit -t 10      # 10 seconds CPU
jq '.' "$INPUT"