CVE-2026-43896

What it actually does

The vulnerability is a local denial-of-service flaw in jq 1.8.1 and earlier. A crafted jq program can trigger unbounded recursion in the jv_object_merge_recursive() function when the * operator is used to recursively merge two JSON objects. Excessive recursion can exhaust the process stack and cause jq to terminate with a segmentation fault. The impact is loss of availability for the jq process or for any automation, script, CI/CD job, data pipeline, API backend, or service that invokes jq on attacker-controlled jq programs or filters. The flaw does not directly provide code execution, data disclosure, or data modification.

Why it matters to the business

Organizations that use jq in automation, data processing, logging, deployment pipelines, or backend services may experience job failures or service disruptions if an attacker or untrusted user can supply jq programs. The practical risk is highest where jq is exposed indirectly through web applications, SaaS workflows, CI systems, ingestion pipelines, or customer-configurable transformations. The CVSS availability impact is high, but current public exploitation signals are low: EPSS is 0.00154, there is no known CISA KEV listing, no ransomware association, and no exploit maturity is currently reported. Because jq is widely embedded in scripts and container images, exposure may be difficult to inventory even when the direct business impact is limited to process crashes.

How an attack unfolds

An attacker first needs a path to influence the jq program or filter that will be executed by a vulnerable jq binary. This may be direct shell access, a job runner, a CI pipeline, a data transformation feature, an API that accepts jq expressions, or a wrapper service that passes user-controlled jq code to the jq command line or library. The attacker then submits a crafted jq program that causes the * operator to recursively merge object operands in a way that drives jv_object_merge_recursive() into unbounded recursion. When the vulnerable code path is reached, the jq process consumes stack until it crashes with a segmentation fault. In standalone command-line use, this causes a single command failure; in automated systems, repeated submissions can cause recurring job failures, service errors, queue backlogs, or degraded availability.

How to fix it

Upgrade jq when a vendor-fixed version is available. No fixed version was provided in the supplied advisory data, so track the jqlang jq upstream security advisory, distribution package advisories, and container base image updates for the corrected release. Until a fixed build is deployed, reduce exposure by preventing untrusted users from supplying arbitrary jq programs or filters, replacing user-supplied jq code with allowlisted transformations, and avoiding use of the recursive object merge pattern on untrusted input. Run jq in a constrained execution context where possible, including process isolation, low privileges, memory and CPU limits, stack limits, job timeouts, and retry limits. For services that expose jq-like transformation features, validate or parse filters before execution and reject use of the * operator for object merges if it is not required. Rebuild containers, scripts, and automation images that bundle jq 1.8.1 or earlier once patched packages are available.

How to confirm the fix worked

Confirm exposure by inventorying jq versions across hosts, containers, CI runners, build images, and application dependencies using commands such as `jq --version` and package manager queries. Versions 1.8.1 and earlier should be considered affected according to the advisory. Confirm mitigation by verifying that systems no longer accept untrusted arbitrary jq programs, that allowlists or filter validation are enforced where applicable, and that jq execution is constrained by timeouts and resource limits. After patching, verify the deployed binary or package version is newer than the affected range or matches the vendor-advised fixed build. Regression-test jq-based workflows that use the * operator with object operands to ensure expected behavior remains intact and crafted recursive merge cases no longer crash the process.

Typical attack path

1. Identify an application, script, CI job, data pipeline, or service that invokes jq 1.8.1 or earlier.
2. Determine whether the jq filter/program is fully or partially attacker-controlled.
3. Submit a crafted jq program using the * operator with object operands that trigger recursive object merge behavior.
4. Cause jv_object_merge_recursive() to recurse without a safe bound.
5. Crash the jq process with a segmentation fault.
6. Repeat submissions if the surrounding service automatically retries jobs or continues accepting transformation requests.

How to detect it

To determine whether this flaw may have been exploited, focus on evidence of jq process crashes rather than traditional intrusion artifacts. Review system logs, kernel logs, container logs, CI/CD job logs, scheduler logs, application logs, and crash-reporting systems for segmentation faults or core dumps involving the jq binary. On Linux systems, check journald, syslog, kernel ring buffers, audit logs, and coredumpctl entries for jq crashes. In containers and Kubernetes, review pod logs, previous container logs, termination reasons, restart counts, and events showing jq exiting due to SIGSEGV or exit code 139. In CI/CD systems, search failed job output for jq segmentation faults or core-dump messages, especially where jobs process untrusted pull requests, artifacts, webhook payloads, or user-supplied transformation expressions. Application teams should inspect request logs or job metadata for user-supplied jq filters containing the * operator used between object-producing expressions shortly before crashes. If core dumps are available, inspect stack traces for jv_object_merge_recursive() or repeated recursive jq object-merge frames. Absence of these artifacts does not prove non-exploitation, because crashes may not be logged or core dumps may be disabled.

• jq: Segmentation fault
• Segmentation fault (core dumped)
• segfault at
• traps: jq
• comm="jq"
• exe="/usr/bin/jq"
• exe="/usr/local/bin/jq"
• jv_object_merge_recursive
• Program terminated with signal SIGSEGV
• exit code 139
• reason: Error
• core.jq
• /var/lib/systemd/coredump/core.jq
• jq --version
• jq-1.8.1

What your security team should do

• Inventory jq usage across servers, containers, developer workstations, CI/CD runners, automation scripts, and data-processing services.
• Prioritize systems where jq filters or programs can be influenced by external users, customers, pull requests, uploaded files, webhook payloads, or job parameters.
• Monitor upstream jqlang jq, operating system vendor, and container image advisories for a fixed release, then upgrade or rebuild affected images promptly.
• Temporarily disable or restrict user-supplied jq programs; prefer predefined, allowlisted transformations.
• Add resource controls around jq execution, including timeouts, stack limits, memory limits, low-privilege execution, and retry throttling.
• Search logs for unexplained jq segmentation faults, core dumps, repeated job failures, or service errors tied to jq execution.
• Review services that wrap jq for API or web use and reject dangerous or unnecessary use of the object recursive merge operator.
• Because this is not currently in KEV and has low EPSS, treat it as a targeted availability risk rather than an emergency internet-wide exploitation event, unless jq execution is exposed to untrusted users.