CVE-2026-44777

What it actually does

The flaw is an availability issue in jq’s module-loading logic. In jq 1.8.2rc1 and earlier, the ordinary module loader does not detect cyclic module inclusion. If one otherwise valid jq module includes another module that includes the first module back, jq can recurse indefinitely until the process exhausts stack or other runtime resources and crashes or hangs. The impact is local denial of service against the jq process or any script, job, build pipeline, service wrapper, or automation that invokes jq against attacker-supplied jq modules or module search paths.

Why it matters to the business

Successful exploitation can interrupt automation that depends on jq, including deployment pipelines, data-processing jobs, monitoring scripts, security tooling, and application startup or configuration workflows. Because jq is widely embedded in scripts and container images, exposure may exist indirectly even where jq is not a primary application dependency. The CVSS score is moderate, EPSS is currently very low, it is not listed in CISA KEV, and no exploit maturity is reported, so broad internet-scale exploitation is unlikely; however, environments that process untrusted jq filters or modules should treat it as a reliability risk.

How an attack unfolds

An attacker needs a path to influence the jq module content or the module search path used by a victim process. They create two or more syntactically valid jq modules where each module includes or imports the other, forming a cycle. When a vulnerable jq version loads the initial module, the module loader follows the include/import chain recursively without tracking modules already being loaded. The recursion continues until jq consumes stack or CPU resources and terminates abnormally, times out, or causes the calling automation to fail. This is most realistic in local tooling, CI/CD jobs, data-transformation workflows, developer workstations, or applications that accept jq filters/modules from users or repositories.

How to fix it

Upgrade jq to a version that includes cycle detection in the ordinary module loader when a fixed release becomes available from the jqlang jq project or your operating-system/package maintainer. No fixed version was provided in the source data, so track vendor advisories and package repositories for the corrected build. Until patched, avoid running jq with untrusted modules or module search paths, do not accept arbitrary jq module files from users, restrict write access to directories used for jq module resolution, pin trusted module directories explicitly, and run jq invocations with process timeouts and resource limits where possible. In CI/CD and automation, review repositories and artifacts for jq module files that include/import each other and fail builds that contain cyclic module graphs.

How to confirm the fix worked

Confirm the installed jq version across hosts, containers, build images, developer environments, and automation runners using commands such as `jq --version` or package-manager inventory. Validate that the deployed package is newer than the affected range once a fixed version is published by the vendor. For exposure validation, identify jq invocations that use `-L`, custom module directories, `include`, `import`, or environment-controlled module resolution, and determine whether those module sources are user-controlled or repository-controlled. Functional validation can be performed in a safe test environment by attempting to load a known cyclic pair of test modules: a fixed jq should reject or stop cyclic loading gracefully rather than recursing until crash, timeout, or stack exhaustion.

Typical attack path

1. Identify a workflow, script, build job, or tool that invokes jq 1.8.2rc1 or earlier with externally supplied modules, filters, repositories, archives, or module search paths.
2. Prepare jq module files that are individually valid but form a cyclic include/import relationship, such as module A loading module B and module B loading module A.
3. Place the malicious modules where jq will resolve them, such as a project directory, configured module path, package artifact, or path referenced by the invoking command.
4. Cause the vulnerable workflow to execute jq and load the attacker-controlled module.
5. The jq module loader recursively follows the cycle without cycle detection, leading to process crash, hang, timeout, or resource exhaustion.
6. The dependent automation, service wrapper, job, or pipeline fails, producing a denial-of-service condition for that operation.

How to detect it

To determine whether this was already exploited, review logs from CI/CD platforms, job schedulers, batch processors, container runtimes, application wrappers, endpoint telemetry, and shell history for jq executions that failed unexpectedly while loading modules. Focus on events involving `jq` commands with `-L` module paths, repository-provided `.jq` files, user-supplied filters, or environment variables affecting module resolution. Look for repeated jq crashes, segmentation faults, stack overflow messages, process timeouts, excessive recursion symptoms, or abnormal exits correlated with newly introduced or modified `.jq` module files. For file-system forensics, inspect jq module directories and recent repository changes for pairs or chains of modules where `include` or `import` statements form a cycle. Because this vulnerability is a denial-of-service condition and not code execution, durable host artifacts may be limited to crash logs, core dumps, job failure records, modified jq module files, and command execution telemetry.

• jq --version
• jq -L
• JQ_LIBRARY_PATH
• include \"
• import \"
• Segmentation fault.*jq
• stack overflow.*jq
• core dumped.*jq
• timeout.*jq
• jq: error
• *.jq

What your security team should do

• Inventory jq installations in base images, developer workstations, CI/CD runners, scripts, appliance images, and production containers; jq is often present as a transitive operational dependency rather than an application dependency.
• Prioritize remediation for systems that execute jq against untrusted repositories, uploaded archives, user-authored filters/modules, or externally controlled module search paths.
• Upgrade to the vendor-fixed jq release as soon as it is available; where OS packages lag, consider using a maintained backport or rebuilding jq from a trusted patched source.
• Add guardrails around jq execution: explicit trusted module directories, no user-writable module paths, execution timeouts, memory/CPU limits, and least-privilege runtime accounts.
• Search code repositories and build artifacts for jq modules with cyclic `include` or `import` relationships, especially where jq modules are accepted from third parties.
• Monitor CI/CD, batch processing, and automation logs for jq crashes, segmentation faults, stack overflows, repeated timeouts, or abnormal termination shortly after loading jq modules.
• Because this issue is not in CISA KEV, not associated with ransomware use, and has very low EPSS, handle it through normal patch management unless jq processes untrusted modules in business-critical workflows.