CVE-2026-43895

What it actually does

This is a NUL-byte path truncation flaw in jq module and data-file import handling. jq 1.8.1 and earlier may accept an import path that contains an embedded NUL byte at the jq language layer, while later resolving the path with C string functions that treat the NUL byte as the end of the string. As a result, validation, allowlist, audit, or policy logic may approve one logical import path while jq actually opens a different, truncated on-disk path. The likely impact is bypass of path restrictions, loading of unintended jq modules, or reading of unintended local data files accessible to the jq process, with limited confidentiality and integrity impact. The attacker generally needs local ability or application-level ability to supply jq filters, jq modules, or import paths used by an automation workflow.

Why it matters to the business

Systems that run jq against filters or modules supplied by users, build pipelines, plugins, or semi-trusted automation may be tricked into loading the wrong local file. This can expose local data available to the jq process or corrupt downstream processing decisions by substituting unexpected jq module logic. The risk is moderated by local/low-privilege requirements, low EPSS, no known KEV listing, and no mature public exploit noted, but organizations using jq in CI/CD, data transformation, security tooling, or policy enforcement should treat untrusted jq input as a higher-risk use case.

How an attack unfolds

An attacker first obtains a way to influence a jq program, module import, data-file import, or wrapper configuration that is later executed by jq 1.8.1 or earlier. They craft an import path containing an embedded NUL byte so that policy or audit code evaluates the full logical string, while jq's lower-level file lookup truncates the path at the NUL byte. If the approved-looking string passes validation, jq may open a different local module or data file than the one that was reviewed or permitted. The attacker then uses the unintended file access to load attacker-controlled jq module logic from an allowed search path, bypass path constraints, or read local JSON data files that the jq process can access. The exploitation remains bounded by the permissions of the jq process and by the ability to influence jq input; it does not inherently provide operating-system command execution.

How to fix it

Upgrade jq when a vendor-provided fixed release becomes available. No fixed version was provided in the input, so track the jqlang jq advisory, operating-system package advisories, container base image updates, and vendor backports. Until patched, do not allow untrusted users to provide jq programs, import statements, module paths, data-file import paths, or jq library search paths. Add a defensive wrapper or pre-execution validation that rejects NUL bytes at the raw byte level before invoking jq, including encoded forms that are decoded before execution. Prefer static, reviewed jq filters stored in trusted locations. Restrict jq execution with least-privilege file permissions, isolated working directories, read-only containers, seccomp/AppArmor/SELinux profiles where feasible, and tightly controlled jq module search paths. Review CI/CD and automation pipelines for jq invocations that consume user-controlled filter files or arguments.

How to confirm the fix worked

Inventory jq installations and flag versions 1.8.1 and earlier using package managers, container image scanners, SBOMs, and `jq --version`. Confirm whether jq is invoked with untrusted or semi-trusted filter input, `include`, `import`, module paths, data-file imports, or custom library search paths. After applying an updated package or mitigation wrapper, perform a controlled validation using a benign jq filter containing an embedded NUL in an import path and confirm the input is rejected before file lookup occurs. Also verify that process command-line logging, CI logs, and application audit logs capture jq invocations sufficiently to investigate suspicious import behavior. For containers and packaged applications, rebuild images after jq is updated and confirm the runtime image no longer contains jq 1.8.1 or earlier.

Typical attack path

1. Identify an application, script, CI job, data pipeline, or developer workflow that runs jq with attacker-influenced filters, modules, import paths, or search paths.
2. Determine whether the jq version is 1.8.1 or earlier and whether any wrapper, policy, or audit logic validates import strings before execution.
3. Craft a jq import or include path containing an embedded NUL byte so that the validator sees one logical path while jq resolves a truncated path on disk.
4. Place or select a target module/data file at the truncated path, or choose an existing readable file that changes the result of the jq execution.
5. Trigger the jq execution through the vulnerable workflow.
6. Use the loaded module or data-file contents to disclose accessible data, bypass a policy decision, or alter downstream transformation results.

How to detect it

To determine whether this was already exploited, focus on places where jq command lines, filter files, module files, and automation logs are retained. Review EDR/process telemetry, Linux auditd, shell history, CI/CD job logs, build logs, application logs that record jq filters, container runtime logs, and source-control changes to jq scripts. Look for jq invocations or filter files containing `import` or `include` statements with NUL-byte representations such as `\u0000`, `\x00`, `%00`, `$'\0'`, or encoded payloads that later decode into those bytes. Compare validated or logged logical import paths with actual file-open telemetry from auditd/eBPF/EDR for the same jq process; a mismatch where jq opens a shorter path prefix is suspicious. Investigate unexpected reads of jq module files, JSON data files, secrets, configuration files, or files outside approved jq library directories by jq processes. Because embedded NULs may not render cleanly in logs, also search for truncated log lines, replacement characters, binary markers, or anomalous jq parse failures near import paths. There are no known KEV or named threat actor associations from the supplied data, so detection should emphasize behavioral evidence rather than campaign-specific indicators.

• jq --version jq-1.8.1
• jq-1.8.1
• import "*.\u0000*"
• include "*.\u0000*"
• import "*\x00*"
• include "*\x00*"
• import "*%00*"
• include "*%00*"
• $'\0'
• $'\x00'
• \u0000
• \x00
• %00
• jq -L
• jq --from-file
• jq -f

What your security team should do

• Prioritize review of environments where jq processes user-supplied filters, repository-controlled filters from untrusted contributors, plugin content, CI/CD inputs, or data transformation rules.
• Inventory jq versions across servers, developer workstations, containers, build agents, and application images; flag jq 1.8.1 and earlier as affected until a fixed/backported package is verified.
• Apply vendor updates as soon as they are available; where no fixed version exists, deploy compensating controls that reject NUL bytes before jq execution.
• Disable or restrict jq module/data-file imports for untrusted workflows, and pin jq library paths to trusted, read-only directories.
• Search recent process execution, shell history, CI job logs, and application logs for jq invocations containing NUL-byte escape patterns or suspicious `import`/`include` paths.
• Ensure jq runs with least privilege and cannot read secrets, source repositories, credentials, or configuration files not required for the transformation task.
• Monitor upstream jqlang jq, OS distribution, and container base-image advisories for the first fixed version or security backport.