CVE-2026-49839

What it actually does

CVE-2026-49839 is a heap out-of-bounds write in jq before version 1.8.2 when processing attacker-controlled input through the `--rawfile` option. If `jq --rawfile` reads an oversized file, `jv_string_append_buf()` can return an invalid “String too long” object, but the raw-file read loop continues and attempts to append additional data to that invalid object. In assertion-enabled builds this typically causes an abort, while assertion-disabled builds can misinterpret the invalid object as a valid string object and perform an out-of-bounds heap write. The practical impact is integrity and availability risk: process crash, memory corruption, and potentially unsafe behavior in tools or automation that invoke jq on untrusted files.

Why it matters to the business

Organizations that use jq in scripts, CI/CD jobs, data-processing pipelines, security tooling, backup workflows, or operational automation may be exposed if those workflows process files supplied or influenced by an attacker. Successful exploitation can disrupt automation by crashing jq-dependent jobs, corrupt processing results, or potentially alter behavior in systems that trust jq output. The CVSS score is high and public exploit availability increases urgency, although exploitation requires a local jq invocation or a workflow that causes jq to process an attacker-controlled file. This issue is not listed in CISA KEV and currently has low EPSS, so prioritize remediation where jq is used on untrusted or externally supplied files.

How an attack unfolds

An attacker first identifies an application, script, build job, import process, or automation task that runs jq with the `--rawfile` option against a file the attacker can create, upload, replace, or otherwise influence. The attacker supplies an oversized file designed to trigger jq’s internal `String too long` condition and ensures the file contains additional data after that point. In vulnerable jq versions, the first oversized append produces an invalid string object, but the read loop continues. The next append reuses the invalid state as though it were a valid string object. In assertion-enabled builds this generally terminates the process, causing a denial of service. In assertion-disabled builds, this can result in a heap out-of-bounds write, causing memory corruption and potentially impacting the integrity or availability of the invoking process or surrounding automation.

How to fix it

Upgrade jq to version 1.8.2 or later wherever jq is installed, embedded, vendored, or packaged into containers, appliances, CI images, developer workstations, and automation runners. Because fixed versions were not provided in the input, use the upstream fixed release `jq 1.8.2` as the minimum safe version and confirm downstream distribution packages have backported the fix if their version number differs. Rebuild container images and static bundles that include jq. As interim mitigations, avoid using `jq --rawfile` on attacker-controlled or externally supplied files, enforce strict file size limits before invoking jq, run jq with least privilege in isolated execution contexts, and ensure automation treats jq crashes as failures rather than continuing with partial or untrusted output.

How to confirm the fix worked

Confirm installed jq versions report 1.8.2 or later using `jq --version`, or verify distribution package changelogs/backport advisories explicitly reference the fix for this vulnerability. Inventory scripts and automation for use of `jq --rawfile` and validate that they do not accept untrusted files without size checks. Rebuild and rescan container images, CI runner images, and application bundles that include jq. Where practical, test representative workflows with large rejected input files to confirm they fail safely without memory corruption, unexpected continuation, or use of partial output. For hardened validation, run the upgraded jq under ASan or equivalent memory diagnostics in a staging environment using oversized raw-file inputs and confirm no heap-buffer-overflow is reported.

Typical attack path

1. Find a workflow, script, CI job, service wrapper, or operator task that invokes vulnerable jq with `--rawfile`.
2. Gain the ability to provide or modify a file that jq will read, such as an uploaded file, generated artifact, repository file, temporary file, or pipeline input.
3. Create an oversized file that causes jq string accumulation to exceed its supported size limit.
4. Ensure the file includes at least one additional byte or chunk after the oversized-string error condition is reached.
5. Trigger the jq execution path so the vulnerable `--rawfile` processing reads the crafted file.
6. Cause jq to abort in assertion-enabled builds or trigger heap memory corruption in assertion-disabled builds.
7. Leverage the resulting crash or corrupted processing state to disrupt automation, tamper with outputs, or attempt further exploitation depending on build hardening and process context.

How to detect it

Review endpoint, application, CI/CD, container, and job execution logs for jq invocations using `--rawfile` against unusually large or externally supplied files. Look for abnormal jq termination, segmentation faults, aborts, core dumps, out-of-memory-like failures, and sanitizer reports around the time large files were processed. On Linux, useful sources include shell history where available, process execution telemetry, auditd/EDR process events, syslog, systemd journal, kernel logs, CI job logs, container stdout/stderr, crash dump directories, and application logs from wrappers that invoke jq. For forensic review, identify large files read shortly before jq crashes, inspect temporary directories and pipeline workspaces for attacker-supplied oversized inputs, and correlate file creation/upload events with jq process failures. If AddressSanitizer or hardened builds were used, search for heap-buffer-overflow reports involving `jv_string_append_buf`, `jv_load_file`, or `jvp_string_ptr`. Absence of these artifacts does not prove non-exploitation because successful or partial memory corruption may leave only a process crash or failed job log.

• jq --rawfile
• jv_invalid_with_msg("String too long")
• String too long
• jv_string_append_buf
• jv_load_file
• jvp_string_ptr
• heap-buffer-overflow
• AddressSanitizer: heap-buffer-overflow
• ERROR: AddressSanitizer
• Segmentation fault
• core dumped
• Aborted
• jq: error
• jq-1.8.1
• jq-1.8.0

What your security team should do

• Prioritize upgrading jq to 1.8.2 or later on systems that process untrusted files, run CI/CD workloads, ingest user uploads, or execute automation with elevated privileges.
• Search code repositories, job definitions, shell scripts, and container images for `jq --rawfile` usage and review whether the referenced files can be attacker-controlled.
• Add pre-execution file size limits and input validation around jq invocations that use `--rawfile`, especially in pipelines and services processing external content.
• Rebuild and redeploy base images, CI runner images, and operational tooling images that include vulnerable jq versions.
• Monitor for jq crashes, abnormal exits, core dumps, and sanitizer messages associated with oversized file processing.
• If jq is exposed through a service or automation interface, isolate execution with least privilege, temporary directories, resource limits, and container or sandbox boundaries.
• Because exploit code is reported available, treat reachable `--rawfile` paths as higher priority even though the vulnerability is not currently in KEV and EPSS is low.