CVE-2026-40164

What it actually does

jq used MurmurHash3 with a fixed, publicly known seed for JSON object hash-table operations. Because the seed was constant, an attacker could precompute many JSON object keys that collide into the same hash bucket. When jq processed such an object, hash-table operations degraded from expected constant time to linear time, causing jq expressions that touch the object to become quadratic in practice. The result is CPU exhaustion and denial of service; the issue does not provide confidentiality or integrity impact by itself.

Why it matters to the business

Systems that process untrusted or attacker-controlled JSON with vulnerable jq builds can be slowed or stalled with a relatively small crafted input. This can disrupt CI/CD jobs, API request handling, ETL/data-processing pipelines, log-processing workflows, automation scripts, and operational tooling that relies on jq. The CVSS availability impact is high, but current known exploitation pressure is lower: EPSS is low and flat, the issue is not in CISA KEV, ransomware use is not reported, and no public exploit maturity is indicated after 120 days since publication.

How an attack unfolds

An attacker identifies a place where JSON they control is passed to jq, such as an API backend, webhook processor, CI/CD pipeline, data-ingestion job, log-processing task, or automation script. Because vulnerable jq versions use a public hardcoded MurmurHash3 seed, the attacker can generate a JSON object whose keys collide into the same internal hash bucket before ever interacting with the target. The attacker then submits the crafted JSON payload to the vulnerable workflow. When jq parses and evaluates expressions over the object, lookups and insertions become increasingly expensive, causing high CPU usage, long runtimes, job timeouts, request failures, or worker exhaustion. Repeated submissions can amplify the effect into sustained service degradation or denial of service.

How to fix it

Upgrade jq to a version or build that includes commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784 or the vendor/backport package containing that fix. Because no exact packaged fixed versions were provided, validate the fix through operating-system, container-image, language-package, and appliance vendor advisories rather than relying only on upstream source history. Rebuild container images and automation runners that embed jq, and update base images where jq is installed transitively. Where immediate upgrade is not possible, reduce exposure by rejecting or size-limiting untrusted JSON objects, enforcing CPU and wall-clock timeouts around jq executions, applying request-rate limits, isolating jq workers, and avoiding jq processing on unauthenticated external input.

How to confirm the fix worked

Inventory jq installations across hosts, containers, build agents, CI images, serverless runtimes, and automation repositories. Confirm that installed binaries or packages are built from a release containing commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784 or a vendor backport. Review package-manager metadata, container image SBOMs, and jq --version output, then map the result to vendor fixed-package advisories. For exposure testing, use a controlled non-production environment and verify that processing adversarial high-collision JSON no longer causes disproportionate CPU time compared with normal JSON of similar size. Also confirm operational safeguards such as process timeouts, resource limits, and input-size limits are active for workflows that run jq on untrusted data.

Typical attack path

1. Find an exposed workflow, service, pipeline, or script that accepts JSON from an untrusted source and invokes jq.
2. Determine that the jq build is vulnerable, either directly through version/build provenance or indirectly through behavior under test input.
3. Generate a JSON object with many keys that collide under jq's fixed MurmurHash3 seed.
4. Submit the crafted JSON object to the affected service or processing workflow.
5. Cause jq to spend excessive CPU time during object processing, slowing or blocking the surrounding application, job, or worker.
6. Repeat or parallelize submissions to sustain denial of service or exhaust processing capacity.

How to detect it

There is no unique payload string or stable network signature for this vulnerability because attackers can generate many different colliding JSON keys. To assess possible exploitation, review application, API gateway, reverse proxy, CI/CD, job scheduler, container, endpoint, and process telemetry for periods where jq processes consumed unusually high CPU or ran far longer than expected after receiving relatively small JSON inputs, especially around 100 KB. Look for repeated request timeouts, worker restarts, pipeline job timeouts, killed jq processes, elevated load average, autoscaling events, or backlog growth tied to JSON-processing endpoints. Correlate suspicious events with inbound requests or queued jobs containing large JSON objects with unusually many object keys and little corresponding business value. On Linux systems, useful sources include process accounting, auditd/execve logs, EDR process telemetry, systemd journal, container runtime logs, Kubernetes pod events, CI runner logs, and application error logs. Treat findings as suspicious when jq execution time or CPU consumption is highly disproportionate to input size, particularly if repeated by the same source IP, account, repository, webhook, queue producer, or external integration.

What your security team should do

• Prioritize patching jq wherever it processes untrusted JSON, especially internet-facing services, webhook consumers, CI/CD runners, data-ingestion systems, and log-processing pipelines.
• Update base images and golden runner images so vulnerable jq binaries are not reintroduced through container rebuilds or automation environments.
• Add CPU, memory, and wall-clock execution limits around jq invocations that may receive external input.
• Apply input validation and request-size limits for JSON objects before they reach jq-based processing paths.
• Search recent operational logs for unexplained jq CPU spikes, job timeouts, worker restarts, and repeated failures following receipt of similarly sized JSON payloads.
• Because EPSS is currently low, not in KEV, and no exploit maturity is reported, handle as high-impact availability hardening rather than an emergency internet-wide exploitation event unless local exposure is high.