Source: jq Version: 1.8.1-5 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for jq. CVE-2026-40612[0]: | jq is a command-line JSON processor. In 1.8.1 and earlier, | jv_contains recurses into nested arrays/objects with no depth limit. | With a sufficiently nested input structure (built programmatically | with reduce, since the JSON parser caps at depth 10000), the C stack | is exhausted. CVE-2026-41256[1]: | jq is a command-line JSON processor. In 1.8.1 and earlier, Top-level | jq programs loaded from a file with -f are truncated at the first | embedded NUL byte on current upstream HEAD. A crafted filter file | such as . followed by \x00 and arbitrary suffix compiles and | executes as only the prefix before the NUL. This leaves jq with a | post-CVE-2026-33948 prefix/full-buffer mismatch on the compilation | path even though the JSON parser path has already been fixed. CVE-2026-41257[2]: | jq is a command-line JSON processor. In 1.8.1 and earlier, the jq | bytecode VM's data stack tracks its allocation size in a signed int. | When the stack grows beyond ≈1 GiB (via deeply nested generator | forks), the doubling arithmetic overflows. The wrapped value is | passed to realloc and then used for a memmove with attacker- | influenced offsets. CVE-2026-43894[3]: | jq is a command-line JSON processor. In 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, causes the function to use a 30-byte stack buffer, and | then writes ≈715 million 16-bit units (≈1.4 GiB) at an offset 1.43 | GiB below the stack frame. The written content is fully attacker- | controlled (the parsed decimal digits, packed 3-per-unit). CVE-2026-43895[4]: | jq is a command-line JSON processor. In 1.8.1 and earlier, jq | accepts embedded NUL bytes in import paths at the jq-language level, | but later resolves those paths through C string operations during | module and data-file lookup. This creates a mismatch between the | logical import string that policy or audit code may validate and the | on-disk path that jq actually opens. CVE-2026-43896[5]: | jq is a command-line JSON processor. In 1.8.1 and earlier, unbounded | recursion in jv_object_merge_recursive() allows a crafted jq program | to crash the process with a segfault. The function is reachable | through the * operator when both operands are objects. CVE-2026-44777[6]: | jq is a command-line JSON processor. In 1.8.2rc1 and earlier, the | ordinary module loader recurses without cycle detection when two | otherwise valid modules include each other. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-40612 https://www.cve.org/CVERecord?id=CVE-2026-40612 [1] https://security-tracker.debian.org/tracker/CVE-2026-41256 https://www.cve.org/CVERecord?id=CVE-2026-41256 [2] https://security-tracker.debian.org/tracker/CVE-2026-41257 https://www.cve.org/CVERecord?id=CVE-2026-41257 [3] https://security-tracker.debian.org/tracker/CVE-2026-43894 https://www.cve.org/CVERecord?id=CVE-2026-43894 [4] https://security-tracker.debian.org/tracker/CVE-2026-43895 https://www.cve.org/CVERecord?id=CVE-2026-43895 [5] https://security-tracker.debian.org/tracker/CVE-2026-43896 https://www.cve.org/CVERecord?id=CVE-2026-43896 [6] https://security-tracker.debian.org/tracker/CVE-2026-44777 https://www.cve.org/CVERecord?id=CVE-2026-44777 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
