CVE-2026-33948

What it actually does

CVE-2026-33948 is an input validation bypass in jq caused by using C string length semantics, specifically strlen(), on buffers read from files or stdin. If an input stream contains an embedded NUL byte, jq treats the NUL as the end of the buffer and parses only the JSON prefix before it, ignoring any trailing bytes. The immediate impact is not arbitrary code execution or direct compromise of jq itself; the risk is a parser differential: jq may approve or transform what appears to be benign JSON while a downstream component that reads the full byte stream may process malicious data after the NUL byte. This can undermine security controls that rely on jq as a JSON validator, policy gate, sanitizer, or pre-processor for untrusted input.

Why it matters to the business

Organizations that use jq in automation, CI/CD pipelines, API gateways, ingestion services, webhook processors, data validation scripts, or security tooling may incorrectly accept attacker-supplied JSON that should have been rejected. The business consequence is integrity risk: malicious configuration, commands, policy changes, records, or payloads may pass a validation step and reach downstream systems. The CVSS score is moderate, EPSS is low and stable, it is not in CISA KEV, and there is no known ransomware association, so this is generally a targeted workflow-abuse risk rather than an internet-scale emergency. However, jq is widely used as infrastructure glue, so exposure may be hidden in scripts, containers, build jobs, and vendor tooling.

How an attack unfolds

An attacker first identifies a workflow where untrusted JSON is passed through jq for validation before being forwarded, stored, interpreted, or acted on by another component. The attacker then crafts an input stream with valid, harmless JSON at the beginning, inserts an embedded NUL byte, and appends malicious trailing data. A vulnerable jq build reads the input but calculates its effective length with strlen(), stopping at the first NUL byte. jq therefore parses only the harmless prefix and may return success, allowing the surrounding workflow to treat the input as valid. If the original byte stream, file, message body, or a separately preserved copy is then consumed by a downstream parser that does not truncate at the NUL byte, that parser may process the malicious suffix. Exploitation depends on this exact chaining condition: jq must be used as a trust boundary, and a later consumer must see more data than jq validated.

How to fix it

Upgrade jq to a version or build that includes commit 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b or later. Where distribution packages are used, update jq from the operating system, container base image, language runtime image, or vendor appliance channel as soon as a patched package is available. Because no exact fixed release version was provided in the input, verify remediation by confirming that the installed jq source or vendor package includes the patch for commit 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b. As defense in depth, do not rely on jq alone as a security boundary for untrusted byte streams; reject JSON inputs containing embedded NUL bytes before validation, ensure the same exact byte sequence validated by jq is the one forwarded downstream, and avoid workflows where one parser validates a truncated view while another parser consumes the full input. For containers and CI images, rebuild images after package updates rather than only patching hosts.

How to confirm the fix worked

Inventory jq versions across hosts, containers, CI runners, build images, serverless packages, appliances, and scripts that vendor a static jq binary. Confirm whether each binary is built from a commit before or after 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b. To test behavior safely, pass jq an input containing a valid JSON prefix, an embedded NUL byte, and trailing non-JSON data; a vulnerable build may accept the prefix instead of rejecting the full malformed stream. Also review workflows to verify that jq is not used as the sole validator for untrusted input that is later consumed by a different parser. Exposure is highest where jq success or jq output is used to authorize, route, store, sign, deploy, or execute data supplied by external users.

Typical attack path

1. Find an application, script, CI job, webhook handler, or ingestion pipeline that accepts attacker-controlled JSON.
2. Determine whether jq is used to validate or pre-screen that JSON before another system consumes it.
3. Craft a payload containing a valid benign JSON prefix followed by an embedded NUL byte and malicious trailing content.
4. Submit the payload through the exposed interface or supply-chain input path.
5. Vulnerable jq validates only the prefix before the NUL byte and returns success or benign output.
6. The surrounding workflow forwards, stores, or otherwise reuses the original input or a fuller byte representation.
7. A downstream parser or consumer processes bytes after the NUL byte, causing the attacker-controlled suffix to influence behavior.

How to detect it

Look for evidence of JSON inputs containing embedded NUL bytes that were accepted or passed through workflows using jq. Relevant log sources include API gateway and reverse-proxy request logs with raw-body capture, application ingestion logs, webhook receiver logs, CI/CD job logs, file upload audit logs, message queue payload archives, data lake ingestion records, EDR file telemetry, and shell/process execution logs showing jq invocation. Because NUL bytes are often not visible in normal text logs, inspect raw payload stores, packet captures, object storage versions, quarantined uploads, and forensic copies with tools that display binary bytes, such as xxd, hexdump, od, ripgrep with binary mode, or Python byte inspection. Indicators of possible exploitation include externally supplied JSON files or request bodies containing byte 0x00, jq validation succeeding on those inputs, and downstream parsers or services acting on data that does not appear in the jq-validated prefix. Also investigate mismatches where jq logs or artifacts show valid JSON but later systems record extra fields, appended objects, parse errors, policy changes, unexpected configuration updates, or command-like content from the same original input. There are no known named threat actors, public exploit maturity is listed as none, EPSS is low and stable, and the issue is not in KEV, so detection should focus on workflow-specific abuse rather than known campaign infrastructure.

• Embedded NUL byte in JSON payload: \x00
• Hex sequence indicating NUL inside JSON input: 00
• jq invoked as JSON validator: jq empty
• jq invoked as JSON validator: jq -e .
• jq invoked on stdin in automation: | jq
• Binary JSON file containing NUL byte: application/json with byte 0x00
• Parser differential pattern: valid JSON prefix before \x00 followed by non-whitespace trailing data
• Forensic command for hunting affected payloads: grep -P "\x00"
• Forensic command for hunting affected payloads: rg -a -U "\x00"

What your security team should do

• Prioritize patching jq in internet-facing ingestion paths, API/webhook processors, CI/CD pipelines, deployment automation, and security validation tooling before lower-risk local administrative uses.
• Search code repositories, containerfiles, scripts, and pipeline definitions for jq used as a validation gate for untrusted JSON, especially patterns such as jq empty, jq -e, or jq . followed by forwarding of the original input.
• Update operating system packages, container base images, and statically bundled jq binaries; verify patched builds include commit 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b or later.
• Add input controls that reject embedded NUL bytes in JSON before jq or any downstream parser processes the data.
• Ensure the exact data validated is the exact data consumed; avoid validating one representation while forwarding another original byte stream.
• Add regression tests with embedded NUL bytes to applications and pipelines that treat jq as a JSON validator.
• Monitor for suspicious JSON submissions containing NUL bytes, especially where validation succeeds but downstream systems log parse errors, policy changes, or unexpected behavior.