jqlang CVE Vulnerabilities & Metrics

Focus on jqlang vulnerabilities and metrics.

Last updated: 12 May 2026, 22:25 UTC

About jqlang Security Exposure

This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with jqlang. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.

For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.

Global CVE Overview

Total jqlang CVEs: 11
Earliest CVE date: 11 Dec 2023, 07:15 UTC
Latest CVE date: 14 Apr 2026, 00:16 UTC

Latest CVE reference: CVE-2026-33948

Rolling Stats

30-day Count (Rolling): 4
365-day Count (Rolling): 7

Calendar-based Variation

Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.

Variations & Growth

Month Variation (Calendar): 0%
Year Variation (Calendar): 600.0%

Month Growth Rate (30-day Rolling): 0.0%
Year Growth Rate (365-day Rolling): 600.0%

Monthly CVE Trends (current vs previous Year)

Annual CVE Trends (Last 20 Years)

Critical jqlang CVEs (CVSS ≥ 9) Over 20 Years

CVSS Stats

Average CVSS: 0.15

Max CVSS: 1.7

Critical CVEs (≥9): 0

CVSS Range vs. Count

Range Count
0.0-3.9 11
4.0-6.9 0
7.0-8.9 0
9.0-10.0 0

CVSS Distribution Chart

Top 5 Highest CVSS jqlang CVEs

These are the five CVEs with the highest CVSS scores for jqlang, sorted by severity first and recency.

All CVEs for jqlang

CVE-2026-33948 jqlang vulnerability CVSS: 0 14 Apr 2026, 00:16 UTC

jq is a command-line JSON processor. Commits before 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b contain a vulnerability where CLI input parsing allows validation bypass via embedded NUL bytes. When reading JSON from files or stdin, jq uses strlen() to determine buffer length instead of the actual byte count from fgets(), causing it to truncate input at the first NUL byte and parse only the preceding prefix. This enables an attacker to craft input with a benign JSON prefix before a NUL byte followed by malicious trailing data, where jq validates only the prefix as valid JSON while silently discarding the suffix. Workflows relying on jq to validate untrusted JSON before forwarding it to downstream consumers are susceptible to parser differential attacks, as those consumers may process the full input including the malicious trailing bytes. This issue has been patched by commit 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b.

CVE-2026-39979 jqlang vulnerability CVSS: 0 13 Apr 2026, 23:16 UTC

jq is a command-line JSON processor. In commits before 2f09060afab23fe9390cce7cb860b10416e1bf5f, the jv_parse_sized() API in libjq accepts a counted buffer with an explicit length parameter, but its error-handling path formats the input buffer using %s in jv_string_fmt(), which reads until a NUL terminator is found rather than respecting the caller-supplied length. This means that when malformed JSON is passed in a non-NUL-terminated buffer, the error construction logic performs an out-of-bounds read past the end of the buffer. The vulnerability is reachable by any libjq consumer calling jv_parse_sized() with untrusted input, and depending on memory layout, can result in memory disclosure or process termination. The issue has been patched in commit 2f09060afab23fe9390cce7cb860b10416e1bf5f.

CVE-2026-33947 jqlang vulnerability CVSS: 0 13 Apr 2026, 22:16 UTC

jq is a command-line JSON processor. In versions 1.8.1 and below, functions jv_setpath(), jv_getpath(), and delpaths_sorted() in jq's src/jv_aux.c use unbounded recursion whose depth is controlled by the length of a caller-supplied path array, with no depth limit enforced. An attacker can supply a JSON document containing a flat array of ~65,000 integers (~200 KB) that, when used as a path argument by a trusted jq filter, exhausts the C call stack and crashes the process with a segmentation fault (SIGSEGV). This bypass works because the existing MAX_PARSING_DEPTH (10,000) limit only protects the JSON parser, not runtime path operations where arrays can be programmatically constructed to arbitrary lengths. The impact is denial of service (unrecoverable crash) affecting any application or service that processes untrusted JSON input through jq's setpath, getpath, or delpaths builtins. This issue has been addressed in commit fb59f1491058d58bdc3e8dd28f1773d1ac690a1f.

CVE-2026-32316 jqlang vulnerability CVSS: 0 13 Apr 2026, 18:16 UTC

jq is a command-line JSON processor. An integer overflow vulnerability exists through version 1.8.1 within the jvp_string_append() and jvp_string_copy_replace_bad functions, where concatenating strings with a combined length exceeding 2^31 bytes causes a 32-bit unsigned integer overflow in the buffer allocation size calculation, resulting in a drastically undersized heap buffer. Subsequent memory copy operations then write the full string data into this undersized buffer, causing a heap buffer overflow classified as CWE-190 (Integer Overflow) leading to CWE-122 (Heap-based Buffer Overflow). Any system evaluating untrusted jq queries is affected, as an attacker can crash the process or potentially achieve further exploitation through heap corruption by crafting queries that produce extremely large strings. The root cause is the absence of string size bounds checking, unlike arrays and objects which already have size limits. The issue has been addressed in commit e47e56d226519635768e6aab2f38f0ab037c09e5.

CVE-2025-9403 jqlang vulnerability CVSS: 1.7 25 Aug 2025, 03:15 UTC

A vulnerability was determined in jqlang jq up to 1.6. Impacted is the function run_jq_tests of the file jq_test.c of the component JSON Parser. Executing manipulation can lead to reachable assertion. The attack requires local access. The exploit has been publicly disclosed and may be utilized. Other versions might be affected as well.

CVE-2025-48060 jqlang vulnerability CVSS: 0 21 May 2025, 18:15 UTC

jq is a command-line JSON processor. In versions up to and including 1.7.1, a heap-buffer-overflow is present in function `jv_string_vfmt` in the jq_fuzz_execute harness from oss-fuzz. This crash happens on file jv.c, line 1456 `void* p = malloc(sz);`. As of time of publication, no patched versions are available.

CVE-2024-23337 jqlang vulnerability CVSS: 0 21 May 2025, 15:16 UTC

jq is a command-line JSON processor. In versions up to and including 1.7.1, an integer overflow arises when assigning value using an index of 2147483647, the signed integer limit. This causes a denial of service. Commit de21386681c0df0104a99d9d09db23a9b2a78b1e contains a patch for the issue.

CVE-2024-53427 jqlang vulnerability CVSS: 0 26 Feb 2025, 16:15 UTC

decNumberCopy in decNumber.c in jq through 1.7.1 does not properly consider that NaN is interpreted as numeric, which has a resultant stack-based buffer overflow and out-of-bounds write, as demonstrated by use of --slurp with subtraction, such as a filter of .-. when the input has a certain form of digit string with NaN (e.g., "1 NaN123" immediately followed by many more digits).

CVE-2023-50268 jqlang vulnerability CVSS: 0 13 Dec 2023, 21:15 UTC

jq is a command-line JSON processor. Version 1.7 is vulnerable to stack-based buffer overflow in builds using decNumber. Version 1.7.1 contains a patch for this issue.

CVE-2023-50246 jqlang vulnerability CVSS: 0 13 Dec 2023, 21:15 UTC

jq is a command-line JSON processor. Version 1.7 is vulnerable to heap-based buffer overflow. Version 1.7.1 contains a patch for this issue.

CVE-2023-49355 jqlang vulnerability CVSS: 0 11 Dec 2023, 07:15 UTC

decToString in decNumber/decNumber.c in jq 88f01a7 has a one-byte out-of-bounds write via the " []-1.2e-1111111111" input. NOTE: this is not the same as CVE-2023-50246. The CVE-2023-50246 71c2ab5 reference mentions -10E-1000010001, which is not in normalized scientific notation.