CVE-2026-40164: jq JSON Processor DoS Vulnerability

CVE-2026-40164 Overview

CVE-2026-40164 is an Algorithmic Complexity Attack vulnerability in jq, the widely-used command-line JSON processor. The vulnerability stems from the use of MurmurHash3 with a hardcoded, publicly visible seed (0x432A9843) for all JSON object hash table operations. This predictable seed allows attackers to precompute key collisions offline and craft malicious JSON payloads that cause severe CPU exhaustion when processed by jq.

Critical Impact

Attackers can cause significant denial of service by supplying a relatively small crafted JSON object (~100 KB) that degrades hash table performance from O(1) to O(n), resulting in O(n²) operation complexity and CPU exhaustion across CI/CD pipelines, web services, and data processing scripts.

Affected Products

• jq versions prior to commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784
• Applications and services utilizing vulnerable jq versions for JSON processing
• CI/CD pipelines and automation scripts dependent on jq

Discovery Timeline

• 2026-04-14 - CVE-2026-40164 published to NVD
• 2026-04-14 - Last updated in NVD database

Technical Details for CVE-2026-40164

Vulnerability Analysis

This vulnerability exploits a fundamental weakness in jq's hash table implementation. The JSON processor relies on MurmurHash3 for efficient key lookups in JSON objects, but critically uses a hardcoded seed value that is publicly visible in the source code. When hash table operations use a predictable seed, an attacker can analyze the hashing algorithm and precompute sets of keys that all hash to the same bucket value.

Under normal operation, hash tables provide O(1) average-case lookup performance by distributing keys across buckets. However, when multiple keys collide into the same bucket, the hash table degrades to a linked list traversal, resulting in O(n) lookup time per operation. For JSON processing that involves multiple lookups across all keys, this transforms typical operations into O(n²) complexity.

What makes this vulnerability particularly concerning is its practicality. Unlike memory corruption vulnerabilities that may require precise exploitation conditions, this attack requires only a carefully crafted JSON payload of approximately 100 KB—well within typical API payload limits and easily delivered through standard channels.

Root Cause

The root cause is the use of a hardcoded cryptographic seed (0x432A9843) in the MurmurHash3 implementation used for JSON object hash tables. This seed is embedded directly in the jq source code and never randomized at runtime. The weakness is classified under CWE-328 (Reversible One-Way Hash), as the predictable seeding undermines the hash function's resistance to collision attacks.

Attack Vector

The attack is network-accessible and requires no authentication or user interaction. An attacker constructs a JSON object containing approximately 100 KB of data where all keys are carefully selected to produce hash collisions when processed with the known seed. When jq parses and processes this malicious JSON, every key lookup operation traverses the same bucket, causing exponential performance degradation.

Common attack scenarios include:

The vulnerability affects any jq expression processing untrusted JSON input. This includes web services that use jq for API response transformation, CI/CD pipelines parsing configuration or artifact metadata, log processing systems, and data transformation scripts accepting external input.

Detection Methods for CVE-2026-40164

Indicators of Compromise

• Unusual CPU spikes when jq processes specific JSON inputs
• Processing time anomalies where small JSON payloads take disproportionately long to complete
• Memory allocation patterns showing abnormal hash table bucket distributions
• Repeated timeout events in services utilizing jq for JSON processing

Detection Strategies

• Monitor CPU utilization metrics for processes executing jq commands with external input
• Implement input size and complexity thresholds for JSON payloads before jq processing
• Deploy application-level logging to track jq execution duration against payload size ratios
• Analyze network traffic for JSON payloads with suspicious key patterns or unusual key repetition structures

Monitoring Recommendations

• Configure alerting for jq process CPU consumption exceeding baseline thresholds
• Implement timeout mechanisms for jq operations processing untrusted input
• Enable detailed logging of JSON payload characteristics including key counts and sizes
• Review and audit systems where jq processes externally-supplied JSON data

How to Mitigate CVE-2026-40164

Immediate Actions Required

• Update jq to a version containing commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784 or later
• Audit all systems and pipelines utilizing jq for JSON processing
• Implement input validation and size limits for JSON payloads processed by jq
• Consider temporary workarounds if immediate patching is not feasible

Patch Information

The vulnerability has been addressed in jq commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784. This patch modifies the hash table implementation to use randomized seeding, preventing attackers from precomputing collision sets. Organizations should update to a jq version that includes this commit.

For detailed patch information, refer to the GitHub Commit and the GitHub Security Advisory GHSA-wwj8-gxm6-jc29.

Workarounds

• Implement strict input validation to reject JSON objects with excessive key counts
• Apply resource limits (cgroups, ulimit) to constrain CPU time for jq processes
• Use preprocessing to sanitize or limit JSON complexity before jq processing
• Consider alternative JSON processing tools for untrusted input until patching is complete

# Example: Limit jq CPU time using timeout
timeout 5s jq '.data' input.json

# Example: Validate JSON key count before processing
KEY_COUNT=$(jq 'if type == "object" then keys | length else 0 end' input.json)
if [ "$KEY_COUNT" -gt 1000 ]; then
    echo "JSON object exceeds maximum key limit"
    exit 1
fi