CVE-2026-41257

What it actually does

jq 1.8.1 and earlier contains a memory-corruption flaw in the bytecode VM data stack. The stack allocation size is tracked with a signed integer; when deeply nested generator forks force stack growth beyond roughly 1 GiB, the size-doubling calculation can overflow, causing a wrapped size to be passed to realloc(). jq may then perform memmove() operations using attacker-influenced offsets against an incorrectly sized buffer. The practical result is process memory corruption, which can cause jq to crash and may allow arbitrary code execution in the context of the jq process depending on allocator behavior, compiler hardening, memory layout, and operating-system mitigations.

Why it matters to the business

This vulnerability mainly affects systems that run jq against untrusted jq filters or untrusted processing workloads, such as automation scripts, CI/CD jobs, data-ingestion tooling, developer workstations, and backend services that invoke jq. Successful exploitation can interrupt automation, corrupt process memory, or potentially run attacker-controlled code with the privileges of the jq process. The current public exploitation signal is low: EPSS is 0.00142 and stable over 30 days, it is not listed in CISA KEV, is not marked as ransomware-used, and no mature public exploit is indicated. However, jq is commonly embedded in operational scripts and container images, so exposure can be widespread even when the vulnerable component is not directly Internet-facing.

How an attack unfolds

An attacker must get a vulnerable jq binary to process a malicious workload, typically by convincing a user, script, pipeline, or service to run jq with an attacker-controlled filter or data-processing expression. The malicious jq program uses deeply nested generator forks to force the VM data stack to grow repeatedly until it exceeds the signed integer size-tracking boundary, around 1 GiB. During stack expansion, the signed integer arithmetic wraps and realloc() receives an incorrect allocation size. jq then performs memmove() using offsets influenced by the malicious workload, producing out-of-bounds memory writes or reads. In the most common outcome, the jq process crashes with a segmentation fault, abort, allocator corruption message, or out-of-memory event. In a more advanced exploitation scenario, an attacker may attempt to shape heap memory and offsets to gain code execution within the jq process, constrained by local execution requirements, high attack complexity, and modern memory protections.

How to fix it

Upgrade jq to a version that contains the vendor fix once available from the jq project or the operating-system/package maintainer. The provided affected range is jq 1.8.1 and earlier, and no exact fixed version was supplied in the input, so treat all versions at or below 1.8.1 as vulnerable until a patched release or backported package is confirmed. Prioritize upgrades in automation paths that process untrusted jq filters, user-submitted data transformations, build artifacts, webhooks, or third-party data. Where immediate upgrade is not possible, avoid running jq with untrusted filters, restrict who can supply jq programs, run jq in a sandboxed or least-privilege context, apply CPU and memory limits, disable core dumps where sensitive data may be present, and isolate jq execution from secrets and privileged filesystem locations. For containerized environments, rebuild images that include vulnerable jq packages rather than only patching hosts.

How to confirm the fix worked

Inventory jq installations and verify versions using package managers and `jq --version`; any result showing jq 1.8.1 or earlier should be considered affected unless the package maintainer documents a backported fix. Check base images, build images, CI runners, developer toolchains, server-side scripts, and embedded copies in application bundles. Confirm remediation by verifying that the installed package version is a patched vendor release or includes the relevant backport, then rerun representative jq workloads to ensure normal operation. For mitigations, validate that untrusted users cannot submit arbitrary jq filters, that jq runs with memory limits below risky thresholds where appropriate, and that service wrappers prevent jq from accessing unnecessary secrets, credentials, or writable paths. Review crash telemetry after patching to confirm that jq-related segmentation faults, allocator corruption errors, and OOM events have stopped.

Typical attack path

1. Identify a workflow, script, service, CI job, container image, or workstation that runs jq 1.8.1 or earlier.
2. Supply or influence the jq filter, script, command-line arguments, or input processing path used by that workflow.
3. Provide a crafted jq expression using deeply nested generator forks that causes VM data stack growth beyond approximately 1 GiB.
4. Trigger the vulnerable stack-resize path, causing signed integer overflow in the allocation-size calculation.
5. Cause realloc() to allocate an incorrectly sized buffer and memmove() to operate with attacker-influenced offsets.
6. Crash the jq process, disrupt the dependent workflow, or attempt further heap manipulation for code execution in the jq process context.

How to detect it

Detection should focus on evidence that jq was driven into abnormal memory behavior or memory corruption. Review endpoint telemetry, shell history, CI/CD logs, job-runner logs, service wrapper logs, container logs, auditd or process execution logs, kernel logs, crash reporters, EDR alerts, and core-dump metadata for jq processes that consumed unusually high memory, crashed with SIGSEGV or SIGABRT, triggered allocator-corruption messages, or were killed by the OOM killer. Look for command lines where jq is passed externally supplied filters, unusually long or generated jq programs, repeated generator-heavy constructs, or processing paths that allow user-provided jq expressions. Because there are no known public threat actors, KEV status, or mature exploit indicators in the provided data, absence of a known IOC does not rule out exploitation. Treat suspicious jq crashes as higher priority when they occur after processing untrusted data, inside automation with access to credentials, or immediately before unexpected file, network, or child-process activity from the same execution context.

• jq-1.8.1
• jq 1.8.1
• /usr/bin/jq
• /usr/local/bin/jq
• /bin/jq
• process.name:jq
• comm="jq"
• exe="/usr/bin/jq"
• exe="/usr/local/bin/jq"
• Segmentation fault (core dumped)
• segfault at
• comm="jq" sig=11
• comm="jq" sig=6
• SIGSEGV
• SIGABRT
• malloc(): corrupted top size
• malloc(): invalid size
• realloc(): invalid next size
• corrupted size vs. prev_size
• double free or corruption
• free(): invalid pointer
• munmap_chunk(): invalid pointer
• Out of memory: Killed process
• Killed process jq
• oom-kill:constraint
• core.jq
• /var/lib/systemd/coredump/core.jq
• /var/crash/jq
• AddressSanitizer: heap-buffer-overflow
• AddressSanitizer: negative-size-param
• ERROR: AddressSanitizer
• memmove

What your security team should do

• Inventory jq usage across endpoints, servers, containers, CI/CD systems, scripts, and data-processing services; flag jq 1.8.1 and earlier as vulnerable.
• Prioritize systems where jq processes untrusted filters, user-controlled transformation expressions, third-party payloads, or data from external integrations.
• Upgrade to the first vendor-fixed jq release or a maintainer package with an explicit backport; rebuild dependent container images and automation runners.
• If no fixed package is available, restrict attacker control over jq filters, run jq under least privilege, enforce memory and CPU limits, and sandbox jq execution.
• Search historical logs for jq crashes, allocator-corruption messages, OOM kills, abnormal memory use above roughly 1 GiB, and suspicious jq command lines using complex generator-heavy filters.
• Add monitoring for repeated jq process crashes, core dumps, SIGSEGV/SIGABRT events, and failed automation jobs involving jq.
• Review jq-executing workflows for exposure to secrets; assume potential process-context compromise if suspicious crashes coincide with attacker-controlled jq input.
• Track upstream jq and distribution advisories because the fixed version was not provided in the input and downstream package versions may differ.