Alan Coopersmith <[email protected]> writes: > https://github.com/jqlang/jq/security/advisories/GHSA-xwrw-4f8h-rjvg states: >> Unbounded Recursion in jv_setpath() / jv_getpath() / delpaths_sorted() >> Affected versions: <= 1.8.1 >> Summary >> ------- >> The jv_setpath(), jv_getpath(), and delpaths_sorted() functions in >> src/jv_aux.c use unbounded recursion where the recursion depth equals the >> length of a caller-supplied path array. There is no depth limit check. >> When a path array with ~60,000 or more elements is supplied — either >> constructed >> by a jq filter expression or provided directly in attacker-controlled JSON >> input >> — the C call stack is exhausted, causing a segmentation fault (SIGSEGV) and >> immediate process crash. >> This vulnerability bypasses the MAX_PARSING_DEPTH (10,000) limit >> that protects >> the JSON parser, because path arrays can be constructed programmatically to >> arbitrary lengths without being constrained by parsing depth. Critically, the >> path array can be sourced entirely from attacker-controlled JSON input, >> making >> this exploitable in scenarios where a trusted jq filter processes untrusted >> data. >> > [See GHSA for code analysis and PoC] >> Impact >> ------ >> - Denial of Service (Crash): Any jq process that calls setpath, getpath, or >> delpaths with a sufficiently long path array will crash with SIGSEGV. >> This is an unrecoverable crash — no error handling is possible. >> - Bypass of existing depth limits: The JSON parser's MAX_PARSING_DEPTH >> (10,000) >> does not protect against this because path arrays are constructed at the jq >> runtime level, not during JSON parsing. An attacker can embed a flat array >> of 65,000 integers in a JSON document (only ~200 KB) that causes a crash >> when used as a path. >> - Affected real-world scenarios: >> - Web services using jq to transform or extract data from user-submitted >> JSON >> - CI/CD pipelines processing untrusted configuration or API responses with >> jq >> - Shell scripts that use setpath/getpath/delpaths on paths derived from >> input >> data >> - Any application embedding libjq where path arguments can be influenced by >> external input >> - Note: Unlike memory corruption vulnerabilities, stack overflow from >> recursion >> is generally not exploitable for code execution on modern systems with >> guard >> pages. The impact is limited to denial of service. >> Severity: Moderate - 6.2 / 10 >> CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H >> CVE ID: CVE-2026-33947 >> Weaknesses: CWE-674 Uncontrolled Recursion >> Credits: @bg0d-glitch > > https://github.com/jqlang/jq/commit/fb59f1491058d58bdc3e8dd28f1773d1ac690a1f > declares that it fixes CVE-2026-33947.
I can see the argument that this a vulnerability if it actually affects libjq. However, I hope it does not become a trend to file CVEs for any stack overflow in command-line programs. Generally the only way to work around that is to force the developer to place arbitrary limits on their program. Note that some systems may have a small stack which crashes before hitting the limit added in the fixed commit. Collin
