Executive Summary

The vulnerability in jq involves how it processes JSON input containing embedded NUL (null) bytes. jq reads input using fgets() but then uses strlen() to determine the length of the input buffer. Since strlen() stops at the first NUL byte, jq truncates the input at that point and only parses the prefix before the NUL byte, ignoring any trailing data after it.

This means an attacker can craft input with a benign JSON prefix followed by a NUL byte and then malicious JSON data. jq will validate only the prefix as valid JSON and silently discard the malicious suffix, leading to a validation bypass.

This issue was fixed by removing the use of strlen() for buffer length calculation and ensuring jq properly rejects JSON input containing embedded NUL bytes instead of truncating it.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can lead to a validation bypass in workflows that rely on jq to validate untrusted JSON input before passing it to downstream consumers.

An attacker can exploit this by embedding a benign JSON prefix before a NUL byte and appending malicious JSON data after it. jq will accept the prefix as valid JSON, but downstream components that process the full input will see the malicious data.

This parser differential can cause security issues because jq's validation is incomplete and misleading, potentially allowing malicious data to be processed unnoticed.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by testing whether jq improperly accepts JSON input containing embedded NUL (null) bytes by truncating the input at the first NUL byte and validating only the prefix. A proof-of-concept involves crafting JSON input with a benign prefix, an embedded NUL byte, and a malicious suffix, then passing it to jq to see if jq accepts only the prefix and ignores the suffix.

A suggested command to detect this issue is to pipe JSON input containing embedded NUL bytes into jq and check if jq incorrectly exits successfully (indicating acceptance of truncated input). For example, using a shell command to test this behavior:

• echo -e '{"role":"user"}\x00{"role":"admin"}' | jq '.'

If jq outputs only the prefix JSON (e.g., {"role":"user"}) and does not error out, it indicates the vulnerability is present. A patched jq version should reject such input and fail.

Useful 0 Not Useful 0

Mitigation Strategies

The immediate mitigation step is to update jq to a version that includes the patch for this vulnerability, specifically the commit 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b, which fixes the improper handling of embedded NUL bytes by removing reliance on strlen() for buffer length calculation.

Until the patched version is deployed, avoid relying solely on jq for validating untrusted JSON input, especially if the input might contain embedded NUL bytes. Consider additional validation steps or alternative JSON parsers that correctly handle such input.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability allows a validation bypass in workflows that rely on jq to validate untrusted JSON inputs before forwarding them to downstream consumers. An attacker can craft input with a benign JSON prefix before an embedded NUL byte followed by malicious trailing data. jq validates only the prefix as valid JSON while silently discarding the suffix, which may contain malicious content.

Such a validation bypass could potentially lead to security issues where malicious data is processed without proper validation, which may impact compliance with standards and regulations like GDPR or HIPAA that require strict data validation and integrity controls.

However, the provided information does not explicitly discuss or analyze the direct impact of this vulnerability on compliance with these standards.

Useful 0 Not Useful 0