jq patches HashDoS CPU exhaustion via hardcoded hash seed

TL;DR — jq can be driven into severe CPU exhaustion with a small crafted JSON object by forcing massive hash collisions in its object hash table, turning typical lookups into O(n²) work.

What happened

jq is a widely used command-line JSON processor that is frequently embedded into automation (e.g., curl | jq), CI/CD pipelines, and data-processing scripts.

CVE-2026-40164 describes an algorithmic complexity denial-of-service (HashDoS) issue: before commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784, jq used MurmurHash3 with a hardcoded public seed (0x432A9843) for JSON object hash table operations. Because the seed is constant and visible, an attacker can precompute colliding keys offline and then submit a crafted JSON object (the CVE notes ~100 KB) where many keys land in the same bucket. That degrades lookups from O(1) to O(n), which can make many jq expressions effectively O(n²) and cause significant CPU exhaustion.

This is a classic “hardcoded hash seed” failure mode: once an attacker can control input keys, they can weaponize collisions into predictable resource exhaustion. It’s especially relevant for modern platform teams because jq often sits in critical automation paths that weren’t designed with adversarial inputs in mind.

Who is impacted

• Any environment that runs jq on attacker-influenced JSON (directly or indirectly), especially:
  • CI/CD pipelines processing untrusted artifacts, logs, or API responses (e.g., curl | jq).
  • Network-facing services that invoke jq on request-supplied JSON.
  • Multi-tenant automation where one tenant can influence JSON processed by shared runners.
• The CVE record identifies the vulnerable range as versions before commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784.

Note: The linked GitHub Security Advisory lists “Affected versions: All versions” and “Patched versions: None” as of publication, which may differ from the CVE record’s “patched in commit” statement; treat this as an indicator to verify your exact build provenance and vendor guidance before assuming you’re covered.

What to do now

• Follow vendor remediation guidance and update jq to a build that includes the upstream fix referenced in the CVE record.
• Identify where jq runs in production automation (pipelines, container images, base AMIs, internal tooling) and flag any callsites that process untrusted JSON.
• Add blast-radius controls where jq processes untrusted inputs:
  • Enforce CPU/time limits and request timeouts around jq execution.
  • Rate-limit or size-limit JSON inputs, and reject unexpectedly large or high-cardinality objects.
  • Prefer running jq in constrained sandboxes/containers for untrusted workloads.
• If you suspect abuse, look for sudden increases in runner CPU time or unusually slow jq steps correlated with specific upstream JSON sources.

Additional Information

• Primary advisory links:
  • CVE record: CVE-2026-40164 (this item’s source).
  • GitHub advisory: GHSA-wwj8-gxm6-jc29 (includes a PoC generator and points to the hardcoded seed in src/jv.c).
• Patch reference (as cited by the CVE): commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784.