CVE-2026-41256

What it actually does

jq versions 1.8.1 and earlier can mishandle top-level jq filter programs loaded from a file with the -f option when the file contains an embedded NUL byte. The compiler treats the program as ending at the first NUL byte, so only the prefix before the NUL is compiled and executed while the remaining bytes are ignored. This creates a parsing/compilation mismatch: tools, reviewers, scanners, or workflows that inspect the full filter file may believe one jq program is being used, while jq actually executes a shorter, attacker-controlled prefix. The practical impact is integrity compromise of data-processing pipelines that execute untrusted or externally supplied jq filter files.

Why it matters to the business

Organizations using jq in scripts, CI/CD jobs, data transformation pipelines, security tooling, or operational automation could have JSON processing logic silently altered if a malicious filter file is introduced. This can lead to incorrect data modification, policy bypass, corrupted generated configuration, misleading reports, or downstream automation making decisions based on manipulated output. The CVSS score is moderate and EPSS is very low with no known KEV listing or mature public exploitation, but jq is widely embedded in operational workflows, so exposure is most important where jq filter files come from repositories, artifacts, tickets, user uploads, vendor packages, or other semi-trusted sources.

How an attack unfolds

An attacker first needs a way to influence a jq filter file that will be executed with jq -f, such as through a pull request, build artifact, shared script repository, uploaded filter, or compromised dependency. They craft a filter file that places malicious or unintended jq logic before an embedded NUL byte and places benign-looking or expected content after the NUL byte. Humans or tooling that inspect the file may evaluate the full visible contents or may not clearly reveal the NUL byte, while vulnerable jq compiles only the prefix before the NUL. When a user or automated process runs jq -f against the crafted filter, jq executes only the attacker-selected prefix, causing the JSON output to be changed, fields to be removed or rewritten, validation logic to be bypassed, or generated artifacts to be corrupted. There is no indication from the provided intelligence that this issue is being exploited by named threat actors, used in ransomware campaigns, or listed in CISA KEV.

How to fix it

Upgrade jq to a version containing the upstream fix once available from the jq project or from the operating system/package distributor. No fixed version was provided in the input, so security teams should track jqlang jq advisories and distribution package updates for a release newer than 1.8.1 that explicitly addresses this issue. Until patched, do not run jq -f on untrusted or externally supplied filter files. Add validation that rejects jq filter files containing embedded NUL bytes before execution. Treat jq filters as executable logic: require code review, restrict write access, pin known-good artifacts, and avoid accepting filters from user-controlled inputs. Where possible, inline fixed filters owned by the application or run jq in constrained build/runtime environments so unexpected output changes cannot directly alter sensitive production state.

How to confirm the fix worked

Confirm installed jq versions across endpoints, build images, containers, and CI runners; versions 1.8.1 and earlier should be considered affected unless the distributor has backported a fix. Validate that package updates replace or patch jq, then test behavior using a non-production filter file containing an embedded NUL byte and confirm the fixed jq rejects it or handles it safely rather than silently compiling only the prefix. Review automation for jq -f usage and verify controls prevent NUL-containing filter files from being introduced. For source repositories and artifact stores, scan .jq files and other jq filter assets for NUL bytes. In CI/CD, add a pre-execution check that fails builds if jq filter files contain byte 0x00.

Typical attack path

1. Identify an organization workflow that runs jq with a filter file using the -f option.
2. Gain influence over that filter file through source control, build artifacts, shared automation, user upload, or another file-delivery path.
3. Create a jq filter containing an embedded NUL byte, with the logic to be executed placed before the NUL and misleading or expected content placed after it.
4. Rely on code review, scanning, or file display tools failing to clearly expose the embedded NUL or the resulting truncation behavior.
5. Wait for a user or automation job to invoke a vulnerable jq version on the crafted file with jq -f.
6. Cause jq to compile and execute only the prefix before the NUL byte, producing attacker-influenced JSON output.
7. Leverage the manipulated output to bypass validation, alter configuration, corrupt data, or mislead downstream automation.

How to detect it

To determine whether this was already exploited, focus on places where jq filter files are stored, changed, and executed. Review source control history, pull requests, artifact repositories, CI/CD logs, shell history, endpoint process telemetry, and file integrity monitoring for jq executions using the -f option and for jq filter files containing embedded NUL bytes. Search repositories and build workspaces for binary jq filter files or files with byte 0x00, especially recent changes after the publication date. Inspect CI/CD job logs and command telemetry for jq -f invocations that consumed newly modified or externally supplied filter files. Compare outputs from affected jobs against expected baselines to identify unexplained JSON field removal, rewriting, policy decision changes, or generated configuration drift. Because exploitation may not produce a distinctive jq error, the strongest evidence is the presence of an embedded NUL byte in a filter file that was executed by jq 1.8.1 or earlier, combined with process or job logs showing jq -f use.

• jq -f
• jq.exe -f
• /usr/bin/jq -f
• /bin/jq -f
• embedded NUL byte in jq filter file
• NUL byte in .jq file
• \x00 in jq filter file
• byte 0x00 in jq filter file
• .jq file containing NUL
• filter file containing NUL

What your security team should do

• Inventory jq usage, prioritizing CI/CD runners, container images, automation scripts, data transformation jobs, and security tooling that invoke jq with the -f option.
• Identify all jq versions at or below 1.8.1 and plan upgrades as soon as fixed vendor packages are available.
• Add immediate compensating controls to reject jq filter files containing embedded NUL bytes before execution.
• Review repositories, artifact stores, and shared script locations for jq filter files containing NUL bytes or unexplained binary content.
• Restrict who can modify jq filter files used by production automation and require review for changes to those files.
• Treat untrusted jq filters as executable content and avoid accepting them from users or external parties.
• Monitor package advisories for jqlang jq and downstream operating system distributions because no fixed version was provided in the input.
• Because EPSS is low, no KEV listing exists, and no mature exploit is reported, prioritize remediation based on exposure: patch internet-fed, user-influenced, or automation-critical workflows first.