[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87qzofoiuh.fsf@gmail.com>
Date: Wed, 15 Apr 2026 17:21:42 -0700
From: Collin Funk <collin.funk1@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: 7 vulnerabilities disclosed & patched in jq
Alan Coopersmith <alan.coopersmith@...cle.com> 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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
