CVE-2026-32316

What it actually does

The flaw is an integer-overflow-to-heap-buffer-overflow condition in jq string handling. In affected jq versions through 1.8.1, jvp_string_append() and jvp_string_copy_replace_bad() can calculate an allocation size using a 32-bit value when the combined string length exceeds 2^31 bytes. The overflow produces an undersized heap allocation, after which jq copies the full string data into that smaller buffer. The most likely technical outcome is process crash and denial of service; depending on allocator behavior, compiler hardening, memory layout, and how jq is embedded or invoked, heap corruption could potentially be abused to alter process memory or achieve further code execution primitives.

Why it matters to the business

Organizations that expose jq processing to untrusted users, automation inputs, APIs, CI/CD jobs, data-transformation services, or multi-tenant workflows could have those services crashed by a crafted jq query or input. The primary business risk is service disruption, failed data-processing pipelines, and degraded availability. Because jq is widely embedded in scripts, containers, build systems, monitoring tooling, and backend transformation services, exposure may exist indirectly even where jq is not considered an internet-facing product. This issue is not currently in CISA KEV, has no known ransomware association, and has a low, flat EPSS score, but the 8.2 CVSS score and unauthenticated attack scenario make internet-exposed or user-driven jq evaluation a higher priority.

How an attack unfolds

An attacker first identifies an application, service, automation endpoint, or workflow that accepts user-controlled jq filters, jq expressions, or JSON inputs that are processed by jq. The attacker then submits a jq program or data combination that causes jq to concatenate or copy strings whose combined length exceeds the vulnerable size boundary. Because affected jq versions do not enforce a maximum string size comparable to array and object limits, the internal allocation size can wrap and allocate a much smaller heap buffer than required. jq then copies the oversized string into that buffer, corrupting heap memory. In typical exploitation, this terminates the jq process or the parent service invoking it, causing denial of service. More advanced exploitation would require shaping heap layout and bypassing memory protections to turn the corruption into controlled memory modification.

How to fix it

Upgrade jq to a version containing the upstream fix for commit e47e56d226519635768e6aab2f38f0ab037c09e5 or to the first vendor/package release that includes that fix. Because the input did not provide exact package-level fixed versions, use operating-system, container-base-image, and language-package advisories to identify the corrected jq package for each distribution. If an upgrade is not immediately available, avoid evaluating untrusted jq programs; restrict users to vetted jq filters; impose strict input, output, and execution-size limits; run jq in a sandboxed, low-privilege process; apply CPU and memory limits; disable core dumps where sensitive data could be exposed; and isolate jq execution from high-privilege services. Treat jq embedded in containers, CI/CD workers, serverless functions, data pipelines, API gateways, and administrative scripts as in scope.

How to confirm the fix worked

Confirm every installed and containerized jq binary is newer than the affected line or includes the upstream fix. Inventory with commands such as `jq --version`, package-manager queries, SBOM scans, and container image scans. Validate that internet-facing or user-driven services do not accept arbitrary jq programs unless jq has been fixed and resource controls are enforced. Where practical, run regression tests using very large string-generation workloads in a non-production environment and confirm jq fails safely with size-limit handling rather than crashing or corrupting memory. For packaged deployments, verify the vendor changelog or patch metadata references the upstream fix commit or the integer-overflow/heap-buffer-overflow issue in jq string handling.

Typical attack path

1. Find an endpoint, job runner, API, plugin, or script path that invokes jq on attacker-controlled filters or JSON content.
2. Confirm the jq version is affected, or infer exposure by behavior and available error messages.
3. Craft jq input that forces very large string concatenation or replacement operations exceeding the vulnerable length boundary.
4. Submit the crafted query or data to the service that evaluates jq.
5. Trigger integer overflow during jq buffer size calculation in string append or copy/replace logic.
6. Cause heap buffer overflow during the subsequent memory copy.
7. Crash jq or the hosting service, or attempt further heap-corruption exploitation if process hardening and memory layout allow it.

How to detect it

Look for evidence of abnormal jq termination, allocator corruption, sanitizer findings, or repeated crashes in services that process user-controlled JSON or jq expressions. Relevant sources include application logs, API gateway logs, job-runner logs, CI/CD logs, container stdout/stderr, systemd journal, syslog, kernel logs, EDR process telemetry, crash dump directories, and core dump metadata. Focus on jq invocations immediately preceded by unusually large JSON payloads, unusually long jq filters, repeated string-concatenation workloads, high memory consumption, OOM-kill events, or abrupt worker restarts. If AddressSanitizer or hardened allocator builds are used, search for heap-buffer-overflow reports referencing jq string routines. For packaged Linux systems, review `/var/log/syslog`, `/var/log/messages`, `journalctl`, container logs, and coredumpctl entries for crashes of the `jq` process. Absence of these artifacts does not prove non-exploitation because a successful denial-of-service attempt may only appear as a generic worker restart or failed transformation job.

• jvp_string_append
• jvp_string_copy_replace_bad
• AddressSanitizer: heap-buffer-overflow
• heap-buffer-overflow
• malloc(): corrupted top size
• malloc(): invalid size
• free(): invalid next size
• double free or corruption
• corrupted size vs. prev_size
• Segmentation fault (core dumped)
• Process terminated: jq
• comm="jq"
• executable: /usr/bin/jq
• /usr/bin/jq
• /usr/local/bin/jq
• core.jq
• jq --version

What your security team should do

• Prioritize remediation for services where users can submit jq filters, expressions, templates, or JSON that is transformed by jq.
• Inventory jq usage across hosts, containers, CI/CD runners, data-processing pipelines, developer tooling, and embedded application dependencies.
• Upgrade jq to a vendor-fixed build or a release containing upstream commit e47e56d226519635768e6aab2f38f0ab037c09e5.
• If patching is delayed, disable arbitrary user-supplied jq evaluation and replace it with an allowlist of approved filters.
• Apply memory, CPU, timeout, and output-size limits to all jq execution paths, especially in multi-tenant or internet-exposed services.
• Run jq under a dedicated low-privilege account or sandbox and isolate it from sensitive files, credentials, and network access.
• Search logs and crash artifacts for jq segmentation faults, heap-corruption messages, sanitizer findings, or repeated abnormal exits.
• Update base images and SBOMs so downstream services do not continue shipping vulnerable jq binaries.