What Was Disclosed
GitHub published advisory GHSA-32cx-cvvh-2wj9 on April 12, 2026 for jq, the command-line JSON processor. The advisory covers CVE-2026-33948, an embedded-NUL truncation issue in jq's normal CLI path for JSON input from files or standard input.
NVD describes the result as a validation bypass. A jq process can accept the JSON before the NUL byte while silently ignoring bytes that follow it, even though another component in the same workflow may still receive or process the full original payload.
How the Bypass Happens
The advisory traces the bug to a byte-length mismatch. jq read input through fgets(), then derived the buffer length with strlen(). Because strlen() stops at the first NUL byte, jq could pass only the prefix to its JSON parser while dropping the trailing bytes from parsing.
That makes this different from a normal syntax error. The leading bytes can be valid JSON, so a check such as jq -c . payload.bin may report a clean value while the original byte stream contains additional content after the NUL. The upstream patch changes the input handling so embedded NULs are not treated as an invisible boundary.
Why JSON Pipelines Are Exposed
The risky pattern is a validator that checks one view of a payload while a downstream system acts on another. NVD calls out workflows that rely on jq to validate untrusted JSON before forwarding, storing, or otherwise using the original bytes. In that setup, jq and the downstream consumer can disagree about what the payload contains.
This is the same class of lesson behind older JSON interoperability research: validation has to happen at the same boundary, with the same bytes, parser, encoding assumptions, and follow-on behavior that production code will use. A syntactically simple payload can still become dangerous when two tools interpret it differently.
Guidance for Developers
If jq is part of an API, CI/CD, security, or data-ingestion path, check vendor packages and upstream builds for the fix associated with commit 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b. Treat jq validation as one control in the pipeline, not as proof that every later consumer will parse identical bytes.
Tool authors should reject or surface embedded NUL bytes clearly, keep validation close to the eventual parser, and avoid forwarding a different byte stream than the one that passed validation. Browser-local tools still benefit from this discipline: keeping pasted JSON in the tab protects privacy, but parser boundaries and byte-level edge cases still need to be explicit.