CVE-2026-39956: jq: Missing runtime type checks for _strindices lead to crash and limited memory disclosure
jq is a command-line JSON processor. Prior to version 1.8.2, the _strindices builtin in jq's src/builtin.c passes its arguments directly to jv_string_indexes() without verifying they are strings, and jv_string_indexes() in src/jv.c relies solely on assert() checks that are stripped in release builds compiled with -DNDEBUG. This allows an attacker to crash jq trivially with input like _strindices(0), and by crafting a numeric value whose IEEE-754 bit pattern maps to a chosen pointer, achieve a controlled pointer dereference and limited memory read/probe primitive. Any deployment that evaluates untrusted jq filters against a release build is vulnerable. This issue has been patched in commit fdf8ef0f0810e3d365cdd5160de43db46f57ed03, which is part of version 1.8.2.
Security readout for executives and security teams
Plain-English summary
jq versions before 1.8.2 can crash or expose limited process-memory information when they evaluate a malicious, untrusted jq filter. The issue is most relevant where users or external systems can supply filters, including automation and shared processing services. Routine use of trusted, fixed filters has lower exposure.
Executive priority
Treat this as a targeted, moderate-priority update, escalating to urgent for internet-facing or multi-user services that evaluate supplied jq filters. The strongest documented business risk is service disruption, with possible limited exposure of process memory. Broad emergency action is not supported by the supplied exploitation evidence.
Technical view
The _strindices builtin omits runtime string-type validation before calling jv_string_indexes(). That function depends on assert() checks removed from release builds compiled with -DNDEBUG. A non-string argument can cause a crash; a crafted numeric value can produce a controlled pointer dereference and limited memory read or probing. Version 1.8.2 includes the correcting commit.
Likely exposure
Exposure exists on jq versions earlier than 1.8.2 when a release build evaluates attacker-controlled or otherwise untrusted filters. Risk is higher in shared services, developer platforms, or automated pipelines accepting filters from users. Systems using only trusted, predefined filters are less likely to be exploitable through this issue.
Exploitation context
The supplied record does not establish active exploitation, and the CVE is not listed as KEV in the bundle. Exploitation requires jq to evaluate an untrusted filter. Documented impact includes an easy denial of service and a more constrained memory disclosure primitive; the sources do not claim code execution or data modification.
Researcher notes
Review trust boundaries around filter text, not merely JSON input. The vulnerable path concerns _strindices receiving an unexpected argument type in release builds where assertions are absent. The cited fix adds validation and ships in 1.8.2. Available evidence supports crash and limited memory probing, but not integrity compromise or remote code execution.
Mitigation direction
Upgrade jq to version 1.8.2 or later.
Prioritize systems that accept jq filters from users or external sources.
Until upgraded, reject untrusted filters and permit only controlled, predefined filters.
Consult the jq advisory when vendor-packaged builds require distribution-specific updates.
Validation and detection
Inventory jq versions across applications, containers, developer systems, and automation workers.
Confirm exposed installations report version 1.8.2 or later.
Identify every workflow where users or external systems can supply jq filters.
Verify untrusted filter submission is blocked wherever upgrades remain pending.
Confirm packaged builds include commit fdf8ef0f0810e3d365cdd5160de43db46f57ed03.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-125: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-125 · source CWE mapping
Out-of-bounds Read
Out-of-bounds Read represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
NULL Pointer Dereference represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Access of Resource Using Incompatible Type ('Type Confusion')
Access of Resource Using Incompatible Type ('Type Confusion') represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.