CVE-2026-43895

The jv_dump_term function in jq 1.5 allows remote attackers to cause a denial of service via a crafted JSON file, leading to stack consumption and application crash. This issue has been fixed in jq 1.6_rc1-r0.

The decNumberCopy function in decNumber.c in jq through 1.7.1 does not properly consider that NaN is interpreted as numeric, which has a resultant stack-based buffer overflow and out-of-bounds write. This can be demonstrated by using --slurp with subtraction, such as a filter of .-. when the input has a certain form.

Off-by-one error in the tokenadd function in jv_parse.c in jq allows remote attackers to cause a denial of service (crash) via a long JSON-encoded number, which triggers a heap-based buffer overflow.

In jq 1.8.1 and earlier, when decNumberFromString is given a number literal of INT_MAX-1 (2147483646) digits, the D2U() macro overflows during signed-int arithmetic. The wrapped negative value bypasses the heap-allocation size check and causes a write of roughly 1.4 GiB of attacker-controlled data outside the stack buffer.

jq is a command-line JSON processor. In 1.8.1 and earlier, the bytecode VM's data stack tracks allocation size in a signed int; when the stack exceeds ~1 GiB, the doubling arithmetic overflows, and the wrapped value is passed to realloc and used in a memmove with attacker-influenced offsets.

In jq 1.8.1 and earlier, top-level jq programs loaded from a file with -f are truncated at the first embedded NUL byte. A crafted filter file compiles and executes as only the prefix before the NUL, leaving a prefix/full-buffer mismatch on the compilation path.

Before commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784, jq used MurmurHash3 with a hardcoded, publicly visible seed (0x432A9843) for all JSON object hash table operations, allowing an attacker to precompute key collisions offline. A crafted JSON object (~100 KB) with all keys hashing to the same bucket degrades lookups from O(1) to O(n), causing CPU exhaustion.

jq is a command-line JSON processor. Commits before 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b contain a vulnerability where CLI input parsing allows validation bypass via embedded NUL bytes. When reading JSON from files or stdin, jq uses strlen() to determine buffer length instead of the actual byte count from fgets(), causing it to truncate input at the first NUL byte and parse only the preceding prefix. This enables an attacker to craft input with a benign JSON prefix before a NUL byte followed by malicious trailing data, where jq validates only the prefix as valid JSON while silently discarding the suffix. Workflows relying on jq to validate untrusted JSON before forwarding it to downstream consumers are susceptible to parser differential attacks, as those consumers may process the full input including the malicious trailing bytes. This issue has been patched by commit 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b.

In the libjq library (part of the jq tool), the jv_parse_sized() function has an out-of-bounds read vulnerability. When processing malformed JSON in a non-NUL-terminated buffer, the error formatting function uses %s which reads until a NUL terminator, ignoring the caller-supplied length.

jq is a command-line JSON processor. Prior to version 1.8.2, the _strindices builtin in jq's src/builtin.c passes its arguments directly to jv_string_indexes() without verifying they are strings, and jv_string_indexes() in src/jv.c relies solely on assert() checks that are stripped in release builds compiled with -DNDEBUG. This allows an attacker to crash jq trivially with input like _strindices(0), and by crafting a numeric value whose IEEE-754 bit pattern maps to a chosen pointer, achieve a controlled pointer dereference and limited memory read/probe primitive.