CVE-2026-43895 Overview
CVE-2026-43895 affects jq, a widely deployed command-line JSON processor maintained by the jqlang project. In versions 1.8.1 and earlier, jq accepts embedded NUL bytes in import paths at the jq-language level but later resolves those paths through C string operations during module and data-file lookup. This mismatch allows the logical import string validated by policy or audit code to differ from the on-disk path that jq actually opens. The flaw is categorized under [CWE-20: Improper Input Validation].
Critical Impact
A local attacker with low privileges can bypass path-based policy checks and cause jq to open files different from those declared in the import statement, leading to limited confidentiality and integrity impact.
Affected Products
- jqlang jq version 1.8.1
- jqlang jq versions earlier than 1.8.1
- Applications and pipelines embedding vulnerable jq releases for module or data-file imports
Discovery Timeline
- 2026-05-11 - CVE-2026-43895 published to NVD
- 2026-05-13 - Last updated in NVD database
Technical Details for CVE-2026-43895
Vulnerability Analysis
The vulnerability stems from inconsistent handling of NUL bytes between the jq language parser and the C-level filesystem layer. The jq language treats import path strings as length-delimited values, permitting embedded NUL (\\u0000) characters within them. When jq later resolves these paths for module loading or data-file lookup, it passes them to standard C library functions that treat NUL as a string terminator.
This discrepancy creates a parser differential. Code that audits or whitelists import strings sees the full logical path, including content after the NUL. The kernel and libc, however, see only the prefix before the NUL byte. An attacker can craft an import like "safe/path\\u0000../../etc/passwd" so policy validates the apparent target while jq opens a different file on disk.
The issue requires local access and low privileges, with no user interaction. Exploitation can disclose data the calling process can read or cause jq to consume unexpected file content as a module, undermining integrity guarantees of automated JSON-processing workflows.
Root Cause
The root cause is improper input validation [CWE-20] across an internal trust boundary. The jq-language layer and the C string layer disagree on what constitutes the end of a string, and no normalization or rejection of NUL bytes occurs before paths cross that boundary.
Attack Vector
Exploitation requires local execution of jq against attacker-influenced filter content or import paths. Common scenarios include shell pipelines that invoke jq on untrusted filter strings, build systems that load jq modules referenced by repository contents, and audit wrappers that pre-validate imports before invoking jq. The attack vector is local with low attack complexity and low privileges required. No verified public proof-of-concept code is available at this time. See the GitHub Security Advisory GHSA-7q7g-mrq3-phxr for technical details.
Detection Methods for CVE-2026-43895
Indicators of Compromise
- Presence of embedded NUL (\\x00) bytes in jq filter strings, import statements, or include directives captured from process command lines or scripts
- jq process opening files whose paths do not match the import strings recorded by upstream audit logging
- Unexpected open() or openat() syscalls from jq targeting sensitive paths such as /etc/, user home directories, or credential stores
Detection Strategies
- Inventory installed jq binaries across endpoints and servers and flag any version at or below 1.8.1
- Inspect shell history, CI/CD job definitions, and automation scripts for jq invocations that pass externally sourced filter or import strings
- Compare logical import strings recorded by application logs against actual file paths opened by jq, alerting on divergence
Monitoring Recommendations
- Enable Linux auditd or equivalent telemetry on execve and openat events for the jq binary to surface anomalous file access
- Ingest endpoint process and file telemetry into a centralized SIEM or data lake to correlate jq executions with sensitive file reads
- Alert on any string passed to jq containing raw NUL bytes, which are not expected in legitimate filters
How to Mitigate CVE-2026-43895
Immediate Actions Required
- Upgrade jq to a fixed release published after 1.8.1 as soon as it is distributed by your operating system or package repository
- Audit applications, scripts, and CI/CD pipelines that pass untrusted input into jq filters or import paths
- Reject or strip NUL bytes from any user-supplied data before it reaches a jq invocation
Patch Information
The jqlang project tracks remediation in GHSA-7q7g-mrq3-phxr. Apply the upstream fix from the jqlang repository or wait for downstream distribution packages that incorporate the patched release. Verify the installed version with jq --version after upgrading.
Workarounds
- Run jq under a restricted user account with filesystem access limited to required directories using tools such as bwrap, firejail, or container sandboxes
- Pre-validate all filter strings and import paths to reject inputs containing NUL bytes before invoking jq
- Avoid passing untrusted JSON or filter content to jq instances that have access to sensitive files
# Configuration example: reject NUL bytes before invoking jq
if printf '%s' "$JQ_FILTER" | grep -q $'\\x00'; then
echo "Rejected: filter contains NUL byte" >&2
exit 1
fi
jq "$JQ_FILTER" input.json
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


