CVE-2026-40164
Hash Collision DoS in jq JSON Processor Causes CPU Exhaustion
Publication date: 2026-04-14
Last updated on: 2026-04-14
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| jqlang | jq | to 0c7d133c3c7e37c00b6d46b658a02244fdd3c784 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-407 | An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached. |
| CWE-328 | The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack). |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in jq, a command-line JSON processor, arises from the use of a fixed, hardcoded seed (0x432A9843) in its MurmurHash3 hashing function for JSON object keys. Because the seed is publicly known and constant, an attacker can precompute many keys that all hash to the same bucket, causing hash table lookups to degrade from efficient O(1) operations to much slower O(n) operations.
When processing a crafted JSON object with many colliding keys (around 100 KB in size), jq's performance degrades to O(n²), significantly increasing CPU usage and causing denial-of-service (DoS) conditions. This makes jq expressions much slower and can exhaust system resources.
The issue was fixed by randomizing the hash seed at process startup, preventing attackers from predicting or controlling hash collisions.
How can this vulnerability impact me? :
This vulnerability can cause denial-of-service (DoS) attacks by exhausting CPU resources when jq processes specially crafted JSON inputs with many colliding keys.
- Significant CPU exhaustion leading to degraded performance or unresponsiveness.
- Slowed or halted processing in systems using jq, such as CI/CD pipelines, web services, and data processing scripts.
- Increased risk of service outages or failures due to the O(n²) complexity induced by the crafted inputs.
Because the attack requires only a relatively small payload (~100 KB), it is practical and easier to exploit compared to other known issues.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by observing unusually high CPU usage or significant delays when jq processes JSON objects, especially those around 100 KB or larger with many keys.
One practical way to detect the vulnerability is to test jq with crafted JSON inputs that cause hash collisions, such as JSON objects with thousands of keys that hash to the same bucket.
A proof-of-concept Python script exists that generates such colliding keys and outputs a JSON object to test jq's performance degradation.
You can run jq on this crafted JSON and monitor CPU usage or execution time to detect if the vulnerability is present.
Specific commands are not provided in the resources, but a general approach would be:
- Generate or obtain a crafted JSON file with many colliding keys (around 100 KB or more).
- Run jq on the crafted JSON file, for example: jq '.' crafted.json
- Monitor CPU usage and execution time using system tools like top, htop, or time command.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to update jq to a version that includes the fix from commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784.
This fix randomizes the hash seed at process startup using a random source, preventing attackers from predicting or controlling hash collisions.
If updating is not immediately possible, consider limiting or validating JSON input sizes and complexity to reduce the risk of crafted payloads causing CPU exhaustion.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in jq causes a denial-of-service (DoS) condition through CPU exhaustion by exploiting predictable hash collisions. This can disrupt availability of services that rely on jq, such as CI/CD pipelines, web services, and data processing scripts.
While the CVE description and resources do not explicitly mention compliance with standards like GDPR or HIPAA, the availability impact caused by this vulnerability could potentially affect compliance with regulations that require maintaining service availability and reliability.
However, there is no direct information provided about specific compliance implications or regulatory violations resulting from this vulnerability.