CVE-2026-39956

What it actually does

This is an improper input validation flaw in jq’s `_strindices` builtin. Vulnerable release builds pass non-string arguments into `jv_string_indexes()` without enforcing type checks; the code relies on `assert()` validation that is removed when jq is compiled with `-DNDEBUG`, which is common for production builds. An attacker who can cause jq to evaluate an untrusted filter can trivially crash the jq process, and with carefully crafted numeric values may cause a controlled pointer dereference that provides a limited memory read/probing primitive. The most reliable impact is denial of service; confidentiality impact is limited but possible where sensitive data is present in the jq process memory.

Why it matters to the business

Organizations that allow users, partners, pipeline inputs, or automated jobs to supply jq filters may experience crashes in JSON-processing workflows, failed automation, interrupted CI/CD or data-processing jobs, and possible exposure of small portions of process memory. The issue is not currently in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS likelihood, and has no public exploit maturity reported, but it remains relevant because jq is widely embedded in scripts, containers, build systems, and operational tooling. Risk is highest where jq filters are accepted from untrusted sources rather than hardcoded by trusted administrators.

How an attack unfolds

An attacker first needs a path to influence the jq filter being evaluated, such as a web feature, automation job, CI workflow, data transformation service, or command wrapper that accepts user-provided jq expressions. The attacker supplies a filter that invokes `_strindices` with a non-string argument, for example a numeric value instead of a string. In vulnerable production builds, the missing runtime type validation allows execution to reach string-indexing logic with an invalid internal value. The simplest outcome is a process crash, causing the calling job or service to fail. A more advanced attacker may craft numeric input whose IEEE-754 representation maps to pointer-like values, attempting limited memory probing or reads from the jq process. Successful exploitation is constrained by the need to control the evaluated filter and by process memory layout, but denial of service is straightforward in exposed workflows.

How to fix it

Upgrade jq to a version or vendor package that includes the upstream fix from commit `fdf8ef0f0810e3d365cdd5160de43db46f57ed03`. No exact fixed release versions were provided in the input, so track distribution advisories and package changelogs for `jqlang jq` and confirm that this commit or an equivalent type-validation fix is present. Where immediate upgrade is not possible, do not evaluate untrusted jq filters; replace user-supplied filters with server-side allowlisted expressions; reject filters containing `_strindices`; run jq in a low-privilege sandbox or container; apply seccomp/AppArmor/SELinux restrictions where feasible; isolate jq execution from sensitive process memory and secrets; enforce execution timeouts and crash containment; and ensure failures in jq do not bring down larger services. Debug/assert-enabled builds may abort earlier but should not be treated as a complete remediation because the correct fix is explicit runtime validation.

How to confirm the fix worked

Inventory jq usage across packages, containers, scripts, CI jobs, and services, then verify installed versions or package builds include the upstream fix commit `fdf8ef0f0810e3d365cdd5160de43db46f57ed03` or an equivalent vendor backport. In a non-production test environment, run a controlled regression test using a malformed filter such as `_strindices(0)`; vulnerable builds may terminate abnormally, crash, or generate a segmentation fault, while fixed builds should reject the input cleanly with a type error or controlled failure. Confirm that externally supplied jq filters are disabled or allowlisted. Review container images and static binaries separately, because bundled jq copies may not match the host package manager version.

Typical attack path

1. Identify an application, API, script, pipeline, or service that invokes jq and allows untrusted or semi-trusted users to provide jq filters.
2. Submit a jq filter that calls `_strindices` with an invalid non-string argument.
3. Trigger jq evaluation in a vulnerable release build compiled without active assertions.
4. Cause the jq process to crash, interrupting the parent workflow or service.
5. Optionally iterate with crafted numeric values to attempt limited memory probing from the jq process address space.
6. Use repeated crashes to disrupt dependent automation, data processing, or service availability.

How to detect it

To determine whether this was already exploited, focus on systems where jq processes untrusted filters. Review application logs, job runner logs, CI/CD logs, shell command audit logs, container logs, systemd journals, crash reporting systems, kernel logs, and endpoint telemetry for abnormal jq termination. Look for filters containing `_strindices` with non-string arguments, repeated jq failures, segmentation faults, core dumps, or stack traces referencing `jv_string_indexes` or `_strindices`. Correlate crashes with user-submitted filter text, API requests, build jobs, scheduled tasks, or automation runs. Examine core dump metadata cautiously for sensitive data exposure, and preserve relevant jq command lines, parent process information, working directories, timestamps, and user/session identifiers. Since no known public exploit or named threat actor activity is reported, detection should be behavior-based rather than actor-specific.

• _strindices(0)
• _strindices(
• jv_string_indexes
• SIGSEGV
• Segmentation fault
• segfault at
• core dumped
• dumped core
• jq.*segfault
• jq.*SIGSEGV
• jq.*core dumped
• Process: jq
• comm="jq"
• /usr/bin/jq
• /bin/jq

What your security team should do

• Prioritize identifying places where jq evaluates user-controlled or externally supplied filters; these are the highest-risk exposure points.
• Upgrade jq packages, container images, and embedded/static jq binaries to builds containing commit `fdf8ef0f0810e3d365cdd5160de43db46f57ed03` or the equivalent vendor backport.
• If upgrades are delayed, block or allowlist jq filters and specifically reject use of `_strindices` from untrusted input paths.
• Run jq jobs with least privilege, no unnecessary secrets in the environment, memory/process isolation, and crash containment.
• Search historical logs for jq crashes, segmentation faults, core dumps, and suspicious `_strindices` usage to assess whether the flaw may already have been triggered.
• Add CI or build-time checks to detect outdated jq binaries in base images, packaged tools, and scripts.
• Because EPSS is currently very low and the issue is not KEV-listed, prioritize based on exposure to untrusted jq filters rather than version presence alone.