CVE-2026-33947

What it actually does

The flaw is an uncontrolled recursion condition in jq runtime path-handling functions jv_setpath(), jv_getpath(), and delpaths_sorted() in src/jv_aux.c. A caller-supplied path array can drive recursive calls far beyond the process call-stack limit because jq's existing MAX_PARSING_DEPTH limit applies to JSON parsing, not to path operations performed by filters such as setpath, getpath, and delpaths. When a trusted jq filter applies one of these builtins to an attacker-controlled, very large path array, jq can crash with SIGSEGV. The practical technical impact is local or input-triggered denial of service of the jq process and any parent service, job, pipeline, or automation that depends on successful jq execution.

Why it matters to the business

Systems that use jq to process untrusted JSON can be made to fail by a relatively small crafted input, potentially interrupting data ingestion, API processing, CI/CD jobs, log processing, security automation, or other JSON-dependent workflows. Because jq is widely embedded in scripts, containers, build pipelines, monitoring tools, and operational automation, the operational blast radius may be larger than direct package inventories suggest. The current public exploitation signal is low: EPSS is 0.00234 and flat over 30 days, it is not in CISA KEV, no ransomware use is reported, and no mature exploit is indicated; however, exploitation is simple where an exposed workflow passes attacker-controlled path arrays into affected jq builtins.

How an attack unfolds

An attacker first identifies an application, script, API, job, or processing pipeline that accepts JSON from an untrusted source and invokes jq with a filter using setpath, getpath, or delpaths. The attacker then submits a crafted JSON value containing a very large flat array, roughly tens of thousands of elements, that is later treated as a jq path argument. During jq execution, the vulnerable path function recurses once per path element without enforcing a depth limit. The recursion exhausts the C stack and the jq process terminates with a segmentation fault. If the calling service does not isolate or recover from jq failures, this can disrupt request handling, batch processing, data transformation, or dependent automation until the workload restarts or the malicious input is removed.

How to fix it

Upgrade jq to a vendor release that includes the fix for commit fb59f1491058d58bdc3e8dd28f1773d1ac690a1f, or apply the vendor/backported patch supplied by the operating system, container base image, language runtime image, or appliance vendor. Because no exact fixed version was provided in the input, treat all jq versions 1.8.1 and below as affected unless the package maintainer explicitly documents that the fix has been backported. Rebuild containers and redeploy images that include vulnerable jq binaries. Where immediate patching is not possible, avoid using setpath, getpath, and delpaths with path arrays derived from untrusted input; enforce an application-level maximum path-array length well below stack-exhaustion levels; reject unexpectedly large JSON arrays used as paths; run jq in a constrained subprocess with time, memory, process, and restart controls; and ensure jq crashes cannot terminate the parent service or cause unbounded retry storms.

How to confirm the fix worked

Confirm exposure by inventorying jq binaries and packages across hosts, containers, CI images, build agents, appliances, and scripts, then checking whether the installed build is version 1.8.1 or below without a documented vendor backport. Review jq filters for use of setpath, getpath, or delpaths where the path argument can be influenced by external JSON. Validate remediation by confirming the package version or vendor changelog includes the fix for commit fb59f1491058d58bdc3e8dd28f1773d1ac690a1f, and by running a controlled regression test in a non-production environment that feeds an oversized path array to representative filters; a fixed build should reject, limit, or safely handle the input without crashing. Also confirm that containers and statically bundled jq binaries were rebuilt, not only host packages updated.

Typical attack path

1. Find an exposed workflow that processes user-supplied or third-party JSON using jq.
2. Determine or infer that the jq filter uses setpath, getpath, or delpaths with input-derived path arrays.
3. Create JSON containing a very large flat array of integers, on the order of approximately 65,000 elements, intended to be interpreted as a path.
4. Submit the crafted JSON through the normal input channel, such as an API request, file upload, message queue, webhook, repository input, or batch feed.
5. jq evaluates the trusted filter and passes the attacker-controlled array into the vulnerable path operation.
6. The jq process exhausts the call stack and crashes with SIGSEGV.
7. The surrounding service, script, worker, or pipeline fails, retries, restarts, or stops processing depending on its error-handling design.

How to detect it

Look for evidence of jq process crashes and repeated failures in systems that process untrusted JSON. Relevant sources include system logs, service manager logs, container runtime logs, Kubernetes pod events, application worker logs, CI/CD job logs, crash dumps, kernel logs, and endpoint telemetry. Search for jq terminating with SIGSEGV, signal 11, segmentation fault, core dumps, abnormal container exits, or repeated restarts shortly after processing JSON inputs. Correlate crash times with inbound requests, uploaded JSON files, webhook deliveries, queue messages, repository events, or batch feeds containing very large flat arrays of numbers. Review command lines and scripts for jq filters containing setpath, getpath, or delpaths. In forensic review, inspect preserved inputs around the crash for arrays with tens of thousands of integer elements that are used as path arguments. There are no known named threat actors, ransomware campaigns, or public exploitation indicators tied to this issue in the provided intelligence, so detection should focus on behavioral crash artifacts and suspicious oversized JSON path arrays rather than actor-specific infrastructure.

• jq
• SIGSEGV
• signal 11
• Segmentation fault
• segfault at
• core dumped
• Process: jq
• comm="jq"
• executable: /usr/bin/jq
• /usr/bin/jq
• /usr/local/bin/jq
• setpath(
• getpath(
• delpaths(
• CrashLoopBackOff
• OOMKilled=false
• exit code 139
• ExitCode=139
• status=139
• core.jq

What your security team should do

• Prioritize patching jq in externally influenced JSON-processing paths, automation platforms, ingestion services, CI/CD systems, webhook processors, and long-running workers.
• Inventory jq usage beyond package managers, including container images, vendored binaries, shell scripts, build images, security tooling, and appliance firmware.
• Identify jq filters using setpath, getpath, or delpaths and determine whether their path arguments can be controlled by users, partners, repositories, queues, or other untrusted sources.
• Add input validation to cap path-array length and reject abnormal arrays before invoking jq.
• Run jq as an isolated subprocess with resource limits and failure containment so a jq crash does not terminate a critical parent process.
• Monitor for repeated jq segmentation faults, worker restarts, failed JSON-processing jobs, or malformed inputs containing unusually large numeric arrays.
• Because current EPSS is low, KEV status is false, and no mature exploit is reported, schedule broad fleet remediation through normal vulnerability management while fast-tracking systems that process untrusted JSON.