CVE-2026-39979

What it actually does

The flaw is an out-of-bounds read in jq's libjq library. The jv_parse_sized() API is intended to parse a caller-supplied buffer using an explicit length, but when malformed JSON triggers an error path, the code formats the input with a string formatter that expects a NUL-terminated C string. If the supplied buffer is not NUL-terminated, libjq can continue reading memory past the end of the buffer while constructing the parse error. Depending on adjacent memory and how the consuming application exposes errors, this can cause process termination, memory disclosure in error output, or instability in services that parse attacker-controlled JSON through libjq.

Why it matters to the business

Applications, services, CLIs, agents, or data-processing pipelines that embed libjq and parse untrusted JSON may be exposed to crashes or unintended disclosure of process memory. The practical impact is most serious where jq is used inside network-reachable services, automation gateways, API processors, log pipelines, CI/CD tooling, or security products that return parse errors to users. This issue is not currently listed in CISA KEV, has no known ransomware association, and has a low EPSS score with no 30-day increase, so broad exploitation appears unlikely at this time; however, the affected component is common enough that embedded or downstream usage should still be inventoried and remediated.

How an attack unfolds

An attacker targets software that uses libjq and specifically calls jv_parse_sized() on untrusted input. The attacker submits malformed JSON in a counted buffer that is not NUL-terminated. When parsing fails, libjq enters its error-construction path and formats the supplied input as a conventional C string rather than respecting the explicit length. The formatter may read past the provided buffer until it encounters a NUL byte in adjacent memory. If the surrounding application returns parse errors to the attacker, nearby memory contents may be exposed in responses or logs. If the read crosses inaccessible memory, the process may crash, resulting in denial of service for the affected application or worker process.

How to fix it

Update jq/libjq to a version that includes commit 2f09060afab23fe9390cce7cb860b10416e1bf5f or a vendor package that backports that fix. Because no specific fixed release version was provided, verify the downstream package changelog or source tree for the patch. Rebuild statically linked software that vendors libjq, not just the system jq binary. Where immediate upgrade is not possible, reduce exposure by avoiding jv_parse_sized() on untrusted non-NUL-terminated buffers, ensuring buffers passed to vulnerable libjq are explicitly NUL-terminated, suppressing detailed parse errors from untrusted users, and isolating JSON-parsing workers with process sandboxing, memory safety hardening, and restart limits.

How to confirm the fix worked

Confirm the installed or embedded libjq source includes commit 2f09060afab23fe9390cce7cb860b10416e1bf5f or an equivalent backport. Check both dynamically linked and statically linked consumers. For packaged deployments, review package changelogs and binary provenance rather than relying only on the jq command-line version. In test environments, exercise libjq consumers with malformed, non-NUL-terminated JSON buffers and confirm parsing fails safely without crashes, AddressSanitizer findings, excessive memory reads, or error messages containing bytes beyond the supplied input. Validate that externally visible services do not echo raw parser internals or memory-adjacent data in error responses.

Typical attack path

1. Identify an application, service, tool, or pipeline that embeds libjq and accepts attacker-controlled JSON input.
2. Send malformed JSON designed to force libjq into its parse-error handling path.
3. Ensure the input reaches jv_parse_sized() as a non-NUL-terminated counted buffer through the consuming application.
4. Trigger the vulnerable formatting path that treats the buffer as a NUL-terminated string.
5. Observe whether the application crashes, returns abnormal parse errors, or leaks adjacent memory contents in responses or logs.
6. Repeat requests to cause service instability or to attempt disclosure of useful in-process data where error output is exposed.

How to detect it

Look for signs of prior exploitation in application logs, API gateway logs, web server logs, crash dumps, container restart events, process supervisor logs, and observability platforms for services that embed libjq. Focus on repeated malformed JSON submissions followed by jq/libjq parse errors, segmentation faults, abnormal worker exits, core dumps, or error responses containing unexpected binary data, fragments of unrelated requests, credentials, environment variables, heap-looking strings, or other data not present in the submitted JSON. For externally reachable services, correlate suspicious parse failures with source IPs, request paths, user agents, and response sizes; unusually large or anomalous error responses after malformed JSON may indicate memory disclosure. In forensic analysis, inspect core files and sanitizer reports for reads originating from jv_parse_sized(), jv_string_fmt(), or libjq parser error handling. There are no public threat actors or campaigns reported for this issue in the provided data, and the low, flat EPSS score suggests exploitation is not currently widespread, but targeted probing may still appear as malformed JSON fuzzing against services that process JSON.

What your security team should do

• Inventory systems and applications that use jq or embed libjq, prioritizing network-facing services and automation that parse untrusted JSON.
• Patch or rebuild affected jq/libjq consumers with the fix containing commit 2f09060afab23fe9390cce7cb860b10416e1bf5f or a vendor-confirmed backport.
• Identify statically linked binaries and container images that may carry vulnerable libjq code even if the host package is patched.
• Temporarily suppress detailed JSON parse errors from untrusted users and ensure malformed input only produces generic client-facing errors.
• Review logs and crash telemetry for repeated malformed JSON parse failures, segmentation faults, abnormal worker restarts, or parser errors containing unexpected binary or memory-like data.
• Add regression tests or fuzzing coverage for libjq parsing paths that pass counted, non-NUL-terminated buffers.
• Treat urgency as moderate unless the vulnerable parser is reachable from unauthenticated remote users or parse errors are externally exposed.