Re: 7 vulnerabilities disclosed & patched in jq

[Collin Funk <collin.funk1 () gmail com>]

Alan Coopersmith <alan.coopersmith () oracle 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