CVE-2026-41257: Jqlang Jq Buffer Overflow Vulnerability

CVE-2026-41257 Overview

CVE-2026-41257 is an integer overflow vulnerability in jq, the widely used command-line JSON processor maintained by the jqlang project. The flaw affects version 1.8.1 and earlier. The jq bytecode virtual machine (VM) tracks its data stack allocation size in a signed integer. When the stack grows beyond approximately 1 GiB through deeply nested generator forks, the doubling arithmetic overflows. The wrapped value is then passed to realloc and used in a memmove call with attacker-influenced offsets. This creates a memory corruption condition that can lead to local code execution when a victim processes a crafted jq program or filter.

Critical Impact

Processing untrusted jq filters can trigger heap memory corruption with attacker-controlled offsets, enabling local code execution and integrity loss.

Affected Products

• jqlang jq version 1.8.1
• jqlang jq versions prior to 1.8.1
• Applications and scripts that pass untrusted input as jq programs or filters

Discovery Timeline

• 2026-05-11 - CVE-2026-41257 published to the National Vulnerability Database (NVD)
• 2026-05-13 - Last updated in NVD database
• 2026-05-17 - EPSS scoring data published

Technical Details for CVE-2026-41257

Vulnerability Analysis

The vulnerability is classified under [CWE-190: Integer Overflow or Wraparound]. The jq bytecode VM maintains an internal data stack used during filter evaluation. The capacity of this stack is stored in a signed int. When jq evaluates deeply nested generator forks, the stack expansion routine doubles the current capacity each time it needs to grow. Once the tracked size approaches the signed integer maximum near 1 GiB, the doubling operation overflows and produces a small or negative value.

The wrapped value flows into a realloc call, producing an undersized heap allocation. Subsequent stack operations invoke memmove using offsets derived from the original (large) logical stack size. This writes past the bounds of the shrunken buffer, corrupting adjacent heap metadata and chunks. An attacker who controls the jq filter being executed can shape the offsets and content of the corrupting writes.

Root Cause

The root cause is the use of a signed int to track an allocation size that scales with attacker-controlled program depth. The size variable is not validated against INT_MAX before the doubling multiplication. There is no saturating arithmetic or pre-allocation overflow check inside the stack growth routine.

Attack Vector

Exploitation is local and requires user interaction. A victim must execute jq against an attacker-supplied filter or pipeline that constructs deeply nested generators sufficient to force the data stack past the 1 GiB threshold. Common exposure paths include build scripts, CI/CD jobs, data processing pipelines, and helper utilities that accept user-provided jq expressions.

No verified public proof-of-concept code is available. The technical mechanism is described in the GitHub Security Advisory GHSA-4jm8-m363-4539.

Detection Methods for CVE-2026-41257

Indicators of Compromise

• jq processes consuming sustained memory above 1 GiB before crashing or aborting
• Crash artifacts referencing realloc, memmove, or stack growth functions in jq core
• Unexpected jq invocations spawned from web servers, build agents, or data pipelines that accept user-supplied filters

Detection Strategies

• Inventory hosts and container images running jq and identify versions at or below 1.8.1 using package managers or jq --version
• Monitor process telemetry for jq invocations with abnormally long command lines or filter arguments sourced from untrusted input
• Review CI/CD pipelines and shell scripts for places where external data is interpolated directly into a jq filter argument

Monitoring Recommendations

• Alert on jq child processes terminating with SIGABRT, SIGSEGV, or out-of-memory conditions on production systems
• Track resident set size (RSS) growth of jq processes exceeding 512 MiB as an early signal of abusive filter execution
• Correlate jq crashes with the originating parent process to identify pipelines exposing untrusted filter input

How to Mitigate CVE-2026-41257

Immediate Actions Required

• Upgrade jq to the fixed release referenced in GHSA-4jm8-m363-4539 across all endpoints, servers, and container base images
• Audit applications that pass user input into jq filters and treat such inputs as untrusted code
• Rebuild and redeploy container images that bundle vulnerable jq binaries

Patch Information

The jqlang maintainers published a security advisory at GHSA-4jm8-m363-4539 covering versions 1.8.1 and earlier. Apply the upstream fix from the official jqlang/jq repository or the corresponding distribution package once available.

Workarounds

• Restrict jq execution to trusted, hard-coded filter expressions and never concatenate untrusted strings into the filter argument
• Enforce per-process resource limits using ulimit -v or systemd MemoryMax= to cap jq memory below 1 GiB, preventing the overflow path from being reached
• Run jq inside a sandbox such as a restricted container, seccomp profile, or unprivileged user when processing data of unknown origin

# Configuration example: cap jq memory and run as unprivileged user
ulimit -v 524288  # 512 MiB virtual memory cap
sudo -u nobody jq -r '.field' < trusted-input.json