CVE-2026-43894

What it actually does

jq 1.8.1 and earlier contains a signed integer overflow in decimal-number parsing. A JSON number literal with approximately INT_MAX-1 digits can cause allocation-size validation to be bypassed, after which jq writes attacker-controlled parsed decimal content far outside the intended stack buffer. The practical confirmed impact is process crash and denial of service through memory corruption; exploitation requires jq to process a specially crafted, extremely large numeric literal, and no fixed version was provided in the input.

Why it matters to the business

Systems, pipelines, APIs, CI jobs, data-processing workflows, or automation that invoke jq on untrusted or attacker-controlled JSON can be crashed, interrupted, or made unreliable. The EPSS score is currently low and the issue is not listed in CISA KEV or ransomware use, but it has been public for 92 days, so organizations should still treat exposed jq usage as a hardening priority, especially where jq is part of automated ingestion or externally reachable processing paths.

How an attack unfolds

An attacker first finds a place where jq is invoked against data they can influence, such as uploaded JSON, API responses, webhook payloads, logs, message queues, CI artifacts, or command-line automation. They then provide a JSON document containing an extraordinarily long decimal number literal. When vulnerable jq versions parse that value, integer arithmetic in the decimal conversion logic wraps, the intended heap allocation check is bypassed, and jq falls back to a small stack buffer. The parser then writes a very large amount of attacker-controlled digit-derived data outside the stack frame, typically terminating jq with a segmentation fault or similar memory-corruption crash. In most realistic deployments this is a denial-of-service condition against the jq process or the workflow depending on it; broader impact depends on whether jq runs inside a resilient, sandboxed, resource-limited environment or inside a critical synchronous processing path.

How to fix it

Upgrade jq to a vendor-fixed release as soon as one is available from the operating-system, container-image, or package maintainer. Because no fixed version was provided, track the jqlang jq security advisory and distribution backports rather than relying only on upstream version strings. Until patched, avoid processing untrusted JSON with jq 1.8.1 or earlier; enforce strict maximum input size and maximum numeric-token length before invoking jq; reject or normalize unusually large number literals; run jq with OS-level resource limits for CPU, memory, file size, and core dumps; isolate jq execution in containers, sandboxes, or low-privilege subprocesses; and ensure job supervisors handle jq crashes without taking down larger services.

How to confirm the fix worked

Inventory jq installations and confirm versions with `jq --version`; treat 1.8.1 and earlier as affected unless a distribution maintainer has documented a backported fix. Review container images, CI runners, build agents, ETL workers, serverless functions, and scripts that bundle or install jq. Validate that upstream controls reject very large JSON inputs and excessive numeric-token lengths before jq is executed. Where a vendor patch is installed, confirm through package changelogs or security advisories that the fix for this parsing overflow is included. In staging, use safe negative tests that verify oversized numeric literals are rejected by input validation or resource controls rather than allowing jq to process unbounded attacker-controlled data.

Typical attack path

1. Identify an application, script, pipeline, or service that invokes jq on data from an untrusted source.
2. Confirm or infer that the jq version is 1.8.1 or earlier.
3. Send or stage a JSON document containing an extremely large decimal number literal near the vulnerable parser boundary.
4. Cause the target workflow to run jq against the crafted JSON.
5. Trigger signed-integer overflow in jq decimal parsing, followed by an out-of-bounds stack write.
6. Observe jq process termination, failed jobs, disrupted data processing, or service errors caused by the crash.

How to detect it

To determine whether exploitation was attempted or successful, review application, job-runner, container, system, and kernel logs for jq crashes or abnormal exits correlated with very large JSON inputs. Useful sources include Linux syslog/journald, kernel `dmesg`, container runtime logs, Kubernetes pod events, CI/CD job logs, API gateway or web server request logs, object-storage access logs, message-queue metadata, EDR process telemetry, and core-dump collectors. Look for `jq` processes exiting with SIGSEGV, SIGABRT, exit code 139, stack-corruption messages, or core files shortly after processing unusually large payloads. Investigate requests, files, messages, or artifacts containing decimal number tokens that are extremely long and not quoted as strings. Because the exploit input is exceptionally large, also search for anomalous multi-gigabyte JSON bodies, failed uploads, truncated logs, storage spikes, or repeated retries against endpoints that invoke jq. No named threat actors or KEV activity were provided; detection should focus on exploitation artifacts and crash correlation rather than actor-specific infrastructure.

• jq: Segmentation fault
• Segmentation fault (core dumped)
• segfault at
• comm="jq"
• program jq
• exit code 139
• SIGSEGV
• SIGABRT
• core dumped
• stack smashing detected
• AddressSanitizer
• decNumberFromString
• D2U
• /usr/bin/jq
• /bin/jq
• jq --version
• jq-1.8.1

What your security team should do

• Prioritize discovery of jq usage in internet-facing ingestion paths, webhook handlers, upload processors, CI/CD systems, ETL jobs, and automation that processes third-party JSON.
• Upgrade or replace jq 1.8.1 and earlier where vendor-fixed packages are available; otherwise track vendor advisories and apply backported security updates promptly.
• Implement compensating controls immediately: maximum JSON body size, maximum numeric literal length, resource limits, sandboxing, and least-privilege execution for jq subprocesses.
• Add monitoring for jq crashes, segmentation faults, abnormal exits, core dumps, and unusually large JSON payloads containing very long numeric tokens.
• Review recent logs and job failures for signs of crafted oversized numeric input, especially in services that accept untrusted JSON.
• Do not assume low EPSS means no risk; prioritize based on exposure and business criticality of workflows that depend on jq.