GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-193

Allowed

Off-by-one Error

Abstraction: Base · Status: Draft

A product calculates or uses an incorrect maximum or minimum value that is 1 more, or 1 less, than the correct value.

278 vulnerabilities reference this CWE, most recent first.

GHSA-GH7J-9W79-XM55

Vulnerability from github – Published: 2026-07-01 06:31 – Updated: 2026-07-09 06:31
VLAI
Details

UltraVNC repeater through 1.8.2.2 contains an off-by-one error in the Base64 decode helper used for HTTP Basic authentication. In repeater/webgui/webutils.c:817, the wi_uudecode() function checks whether the input length exceeds the output buffer with a strict greater-than comparison (>), while the correct check should be greater-than-or-equal (>=). When strlen(authdata) equals sizeof(decode), the decoded output length (approximately 3/4 of input) does not overflow the buffer in current practice because the outer HTTP request bounds constrain the Authorization header. However, the defective check leaves a latent off-by-one condition that could become exploitable if the buffering constraints change. The current risk is limited to a one-byte write at the boundary of a 1024-byte stack buffer under constrained conditions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-44042"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-193"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-01T05:16:21Z",
    "severity": "LOW"
  },
  "details": "UltraVNC repeater through 1.8.2.2 contains an off-by-one error in the Base64 decode helper used for HTTP Basic authentication. In repeater/webgui/webutils.c:817, the wi_uudecode() function checks whether the input length exceeds the output buffer with a strict greater-than comparison (\u003e), while the correct check should be greater-than-or-equal (\u003e=). When strlen(authdata) equals sizeof(decode), the decoded output length (approximately 3/4 of input) does not overflow the buffer in current practice because the outer HTTP request bounds constrain the Authorization header. However, the defective check leaves a latent off-by-one condition that could become exploitable if the buffering constraints change. The current risk is limited to a one-byte write at the boundary of a 1024-byte stack buffer under constrained conditions.",
  "id": "GHSA-gh7j-9w79-xm55",
  "modified": "2026-07-09T06:31:59Z",
  "published": "2026-07-01T06:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44042"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ultravnc/UltraVNC"
    },
    {
      "type": "WEB",
      "url": "https://uvnc.com"
    },
    {
      "type": "WEB",
      "url": "https://www.securin.io/zero-days/cve-2026-44042-wi-uudecode-off-by-one-bounded-ultravnc-repeater"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GJQW-R32J-J6WQ

Vulnerability from github – Published: 2022-05-24 17:49 – Updated: 2024-03-21 03:34
VLAI
Details

In mjs_json.c in Cesanta MongooseOS mJS 1.26, a maliciously formed JSON string can trigger an off-by-one heap-based buffer overflow in mjs_json_parse, which can potentially lead to redirection of control flow.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-31875"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-193",
      "CWE-787"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-29T02:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "In mjs_json.c in Cesanta MongooseOS mJS 1.26, a maliciously formed JSON string can trigger an off-by-one heap-based buffer overflow in mjs_json_parse, which can potentially lead to redirection of control flow.",
  "id": "GHSA-gjqw-r32j-j6wq",
  "modified": "2024-03-21T03:34:04Z",
  "published": "2022-05-24T17:49:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31875"
    },
    {
      "type": "WEB",
      "url": "https://github.com/418sec/mjs/pull/2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cesanta/mjs/releases/tag/1.26"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/1-other-mjs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GMQ8-994R-JV83

Vulnerability from github – Published: 2026-03-12 00:31 – Updated: 2026-03-16 12:35
VLAI
Summary
yauzl contains an off-by-one error
Details

yauzl (aka Yet Another Unzip Library) version 3.2.0 for Node.js contains an off-by-one error in the NTFS extended timestamp extra field parser within the getLastModDate() function. The while loop condition checks cursor < data.length + 4 instead of cursor + 4 <= data.length, allowing readUInt16LE() to read past the buffer boundary. A remote attacker can cause a denial of service (process crash via ERR_OUT_OF_RANGE exception) by sending a crafted zip file with a malformed NTFS extra field. This affects any Node.js application that processes zip file uploads and calls entry.getLastModDate() on parsed entries. Fixed in version 3.2.1.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "yauzl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "fixed": "3.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.2.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-31988"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-193"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T18:58:11Z",
    "nvd_published_at": "2026-03-11T23:16:00Z",
    "severity": "MODERATE"
  },
  "details": "yauzl (aka Yet Another Unzip Library) version 3.2.0 for Node.js contains an off-by-one error in the NTFS extended timestamp extra field parser within the getLastModDate() function. The while loop condition checks cursor \u003c data.length + 4 instead of cursor + 4 \u003c= data.length, allowing readUInt16LE() to read past the buffer boundary. A remote attacker can cause a denial of service (process crash via ERR_OUT_OF_RANGE exception) by sending a crafted zip file with a malformed NTFS extra field. This affects any Node.js application that processes zip file uploads and calls entry.getLastModDate() on parsed entries. Fixed in version 3.2.1.",
  "id": "GHSA-gmq8-994r-jv83",
  "modified": "2026-03-16T12:35:31Z",
  "published": "2026-03-12T00:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31988"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thejoshwolfe/yauzl/commit/c4695215b05c6adffda613b9051a2a85429b33fe"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thejoshwolfe/yauzl"
    },
    {
      "type": "WEB",
      "url": "https://www.codeant.ai/security-research/yauzl-denial-of-service-zip-file-crash"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/yauzl"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/yauzl-denial-of-service-via-off-by-one-error-in-ntfs-timestamp-parser"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "yauzl contains an off-by-one error"
}

GHSA-GW5P-Q8MJ-P7GH

Vulnerability from github – Published: 2023-09-14 19:33 – Updated: 2025-05-02 12:53
VLAI
Summary
Miscompilation of wasm `i64x2.shr_s` instruction with constant input on x86_64
Details

Impact

Wasmtime versions from 10.0.0 to 12.0.1 contain a miscompilation of the WebAssembly i64x2.shr_s instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the i64x2.shr_s with a constant shift amount larger than 32 may produce an incorrect result.

This issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless.

This issue was discovered through fuzzing of Wasmtime's code generator Cranelift.

Patches

Wasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation.

Workarounds

This issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to disable the SIMD proposal for WebAssembly. Users prior to 10.0.0 are unaffected by this vulnerability.

References

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "12.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-41880"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-193"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-14T19:33:17Z",
    "nvd_published_at": "2023-09-15T20:15:11Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nWasmtime versions from 10.0.0 to 12.0.1 contain a miscompilation of the WebAssembly `i64x2.shr_s` instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the `i64x2.shr_s` with a constant shift amount larger than 32 may produce an incorrect result.\n\nThis issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless.\n\nThis issue was discovered through fuzzing of Wasmtime\u0027s code generator Cranelift.\n\n### Patches\n\nWasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation.\n\n### Workarounds\n\nThis issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to [disable the SIMD proposal for WebAssembly](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd). Users prior to 10.0.0 are unaffected by this vulnerability.\n\n### References\n\n* [PR which introduced this bug to Wasmtime](https://github.com/bytecodealliance/wasmtime/pull/6372)\n* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/B8PJgg6bEdg)",
  "id": "GHSA-gw5p-q8mj-p7gh",
  "modified": "2025-05-02T12:53:12Z",
  "published": "2023-09-14T19:33:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-gw5p-q8mj-p7gh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-gw5p-q8mj-p7gh#:~:text=Mailing%20list%20announcement"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41880"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/pull/6372"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/commit/8d7eda15b0badcbea83a7aac2d08f80788b59240"
    },
    {
      "type": "WEB",
      "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bytecodealliance/wasmtime"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2023-0091.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Miscompilation of wasm `i64x2.shr_s` instruction with constant input on x86_64"
}

GHSA-H37V-HP6W-2PP8

Vulnerability from github – Published: 2026-02-02 20:33 – Updated: 2026-02-02 20:33
VLAI
Summary
ml-dsa's UseHint function has off by two error when r0 equals zero
Details

Summary

There's a bug in the use_hint function where it adds 1 instead of subtracting 1 when the decomposed low bits r0 equal exactly zero. FIPS 204 Algorithm 40 is pretty clear that r0 > 0 means strictly positive, but the current code treats zero as positive. This causes valid signatures to potentially fail verification when this edge case gets hit.

Details

The issue is in ml-dsa/src/hint.rs in the use_hint function. Here's what FIPS 204 Algorithm 40 says:

3: if h = 1 and r0 > 0  return (r1 + 1) mod m
4: if h = 1 and r0 <= 0  return (r1 − 1) mod m

Line 3 uses r0 > 0 (strictly greater than zero), and line 4 uses r0 <= 0 (less than or equal, which includes zero). So when r0 = 0, the spec says to subtract 1.

But the current implementation does this:

if h && r0.0 <= gamma2 {
    Elem::new((r1.0 + 1) % m)
} else if h && r0.0 >= BaseField::Q - gamma2 {
    Elem::new((r1.0 + m - 1) % m)
}

The problem is r0.0 <= gamma2 includes zero. When r0 = 0, this condition is true (since 0 <= gamma2), so it adds 1. But according to the spec, r0 = 0 should fall into the r0 <= 0 case and subtract 1 instead.

The result is +1 when it should be -1, which is an off by two error mod m.

PoC

Take MLDSA 44 where γ2 = 95,232 and m = 44.

If use_hint(true, 0) is called: - Decompose(0) gives (r1=0, r0=0) - The condition r0.0 <= gamma2 is 0 <= 95232 which is true - So it returns (0 + 1) % 44 = 1

But FIPS 204 says: - r0 > 0 is 0 > 0 which is false - r0 ≤ 0 is 0 ≤ 0 which is true - So it should return (0 - 1) mod 44 = 43

The function returns 1 when it should return 43.

This can happen in real signatures whenever any coefficient of the w' vector happens to be a multiple of 2γ2, which makes its decomposed r0 equal zero. It's not super common but it's definitely possible, and when it hits, verification will fail for a completely valid signature.

Impact

This is a FIPS 204 compliance bug that affects signature verification. When the edge case triggers, valid signatures get rejected. Since MLDSA is supposed to be used for high security post quantum cryptography, having verification randomly fail isn't great. It's also theoretically possible that the mismatch between what signing expects and what verification does could be exploited somehow, though that would need more looking into.

The fix is straightforward, just change the condition to explicitly check for positive values:

if h && r0.0 > 0 && r0.0 <= gamma2 {
    Elem::new((r1.0 + 1) % m)
} else if h {
    Elem::new((r1.0 + m - 1) % m)
}
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.1.0-rc.4"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "ml-dsa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.0-rc.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-193",
      "CWE-682"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-02T20:33:08Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThere\u0027s a bug in the `use_hint` function where it adds 1 instead of subtracting 1 when the decomposed low bits `r0` equal exactly zero. FIPS 204 Algorithm 40 is pretty clear that `r0 \u003e 0` means strictly positive, but the current code treats zero as positive. This causes valid signatures to potentially fail verification when this edge case gets hit.\n\n### Details\n\nThe issue is in `ml-dsa/src/hint.rs` in the `use_hint` function. Here\u0027s what FIPS 204 Algorithm 40 says:\n\n```\n3: if h = 1 and r0 \u003e 0  return (r1 + 1) mod m\n4: if h = 1 and r0 \u003c= 0  return (r1 \u2212 1) mod m\n```\n\nLine 3 uses `r0 \u003e 0` (strictly greater than zero), and line 4 uses `r0 \u003c= 0` (less than or equal, which includes zero). So when `r0 = 0`, the spec says to subtract 1.\n\nBut the current implementation does this:\n\n```rust\nif h \u0026\u0026 r0.0 \u003c= gamma2 {\n    Elem::new((r1.0 + 1) % m)\n} else if h \u0026\u0026 r0.0 \u003e= BaseField::Q - gamma2 {\n    Elem::new((r1.0 + m - 1) % m)\n}\n```\n\nThe problem is `r0.0 \u003c= gamma2` includes zero. When `r0 = 0`, this condition is true (since `0 \u003c= gamma2`), so it adds 1. But according to the spec, `r0 = 0` should fall into the `r0 \u003c= 0` case and subtract 1 instead.\n\nThe result is +1 when it should be -1, which is an off by two error mod m.\n\n### PoC\n\nTake MLDSA 44 where \u03b32 = 95,232 and m = 44.\n\nIf `use_hint(true, 0)` is called:\n- `Decompose(0)` gives `(r1=0, r0=0)`\n- The condition `r0.0 \u003c= gamma2` is `0 \u003c= 95232` which is true\n- So it returns `(0 + 1) % 44 = 1`\n\nBut FIPS 204 says:\n- `r0 \u003e 0` is `0 \u003e 0` which is false\n- `r0 \u2264 0` is `0 \u2264 0` which is true\n- So it should return `(0 - 1) mod 44 = 43`\n\nThe function returns 1 when it should return 43.\n\nThis can happen in real signatures whenever any coefficient of the `w\u0027` vector happens to be a multiple of 2\u03b32, which makes its decomposed `r0` equal zero. It\u0027s not super common but it\u0027s definitely possible, and when it hits, verification will fail for a completely valid signature.\n\n### Impact\n\nThis is a FIPS 204 compliance bug that affects signature verification. When the edge case triggers, valid signatures get rejected. Since MLDSA is supposed to be used for high security post quantum cryptography, having verification randomly fail isn\u0027t great. It\u0027s also theoretically possible that the mismatch between what signing expects and what verification does could be exploited somehow, though that would need more looking into.\n\nThe fix is straightforward, just change the condition to explicitly check for positive values:\n\n```rust\nif h \u0026\u0026 r0.0 \u003e 0 \u0026\u0026 r0.0 \u003c= gamma2 {\n    Elem::new((r1.0 + 1) % m)\n} else if h {\n    Elem::new((r1.0 + m - 1) % m)\n}\n```",
  "id": "GHSA-h37v-hp6w-2pp8",
  "modified": "2026-02-02T20:33:08Z",
  "published": "2026-02-02T20:33:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/RustCrypto/signatures/security/advisories/GHSA-h37v-hp6w-2pp8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RustCrypto/signatures/commit/10f4ff04cb43ef2b789ee06e885f11cd054b1335"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/RustCrypto/signatures"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "ml-dsa\u0027s UseHint function has off by two error when r0 equals zero"
}

GHSA-H835-4P8W-83C9

Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14
VLAI
Details

UltraVNC revision 1206 has multiple off-by-one vulnerabilities in VNC client code connected with improper usage of ClientConnection::ReadString function, which can potentially result code execution. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1207.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-8268"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-193"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-08T23:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "UltraVNC revision 1206 has multiple off-by-one vulnerabilities in VNC client code connected with improper usage of ClientConnection::ReadString function, which can potentially result code execution. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1207.",
  "id": "GHSA-h835-4p8w-83c9",
  "modified": "2022-05-13T01:14:29Z",
  "published": "2022-05-13T01:14:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8268"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-927095.pdf"
    },
    {
      "type": "WEB",
      "url": "https://ics-cert.kaspersky.com/advisories/klcert-advisories/2019/03/01/klcert-19-015-ultravnc-off-by-one-error"
    },
    {
      "type": "WEB",
      "url": "https://www.us-cert.gov/ics/advisories/icsa-20-161-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H88Q-M8MM-7243

Vulnerability from github – Published: 2026-06-30 15:30 – Updated: 2026-09-01 03:31
VLAI
Details

A flaw was found in GLib. An off-by-one error can occur in the g_key_file_get_locale_string_list function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-58014"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-193"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-30T13:19:17Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in GLib. An off-by-one error can occur in the g_key_file_get_locale_string_list function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.",
  "id": "GHSA-h88q-m8mm-7243",
  "modified": "2026-09-01T03:31:03Z",
  "published": "2026-06-30T15:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58014"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:49512"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:55440"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:57015"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:58981"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:61766"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:61783"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-58014"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492255"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.gnome.org/GNOME/glib/-/issues/3930"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H8V6-GRJ2-PFX5

Vulnerability from github – Published: 2022-08-05 00:00 – Updated: 2022-08-11 00:00
VLAI
Details

Crow before v1.0+4 was discovered to contain a buffer overflow via the function qs_parse at query_string.h. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-34970"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-193"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-04T19:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Crow before v1.0+4 was discovered to contain a buffer overflow via the function qs_parse at query_string.h. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input.",
  "id": "GHSA-h8v6-grj2-pfx5",
  "modified": "2022-08-11T00:00:31Z",
  "published": "2022-08-05T00:00:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34970"
    },
    {
      "type": "WEB",
      "url": "https://github.com/CrowCpp/Crow/pull/486"
    },
    {
      "type": "WEB",
      "url": "https://cwe.mitre.org/data/definitions/193.html"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0xhebi/CVE-2022-34970/blob/master/report.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/CrowCpp/Crow/releases/tag/v1.0%2B4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HHQ9-4HJ5-WJVR

Vulnerability from github – Published: 2023-02-14 00:30 – Updated: 2023-02-22 21:30
VLAI
Details

Off-by-one Error in GitHub repository gpac/gpac prior to v2.3.0-DEV.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-0818"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-193"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-13T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Off-by-one Error in GitHub repository gpac/gpac prior to v2.3.0-DEV.",
  "id": "GHSA-hhq9-4hj5-wjvr",
  "modified": "2023-02-22T21:30:38Z",
  "published": "2023-02-14T00:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0818"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gpac/gpac/commit/377ab25f3e502db2934a9cf4b54739e1c89a02ff"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/038e7472-f3e9-46c2-9aea-d6dafb62a18a"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5411"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HM4X-R5HC-794F

Vulnerability from github – Published: 2025-08-25 15:53 – Updated: 2025-11-03 21:34
VLAI
Summary
ImageMagick has a Heap Buffer Overflow in InterpretImageFilename
Details

Heap Buffer Overflow in InterpretImageFilename

Summary

A heap buffer overflow was identified in the InterpretImageFilename function of ImageMagick. The issue stems from an off-by-one error that causes out-of-bounds memory access when processing format strings containing consecutive percent signs (%%).

Environment

  • OS: Arch Linux (Linux gmkhost 6.14.2-arch1-1 # 1 SMP PREEMPT_DYNAMIC Thu, 10 Apr 2025 18:43:59 +0000 x86_64 GNU/Linux (GNU libc) 2.41)
  • Architecture: x86_64
  • Compiler: gcc (GCC) 15.1.1 20250425

Reproduction

Build Instructions

# Clone the repository
git clone https://github.com/ImageMagick/ImageMagick.git
cd ImageMagick
git reset --hard 8fff9b4f44d2e8b5cae2bd6db70930a144d15f12

# Build with AddressSanitizer
export CFLAGS="-fsanitize=address -g -O1"
export CXXFLAGS="-fsanitize=address -g -O1"
export LDFLAGS="-fsanitizer=address"
./configure
make

# Set library path and trigger the crash
export LD_LIBRARY_PATH="$(pwd)/MagickWand/.libs:$(pwd)/MagickCore/.libs:$LD_LIBRARY_PATH"
./utilities/.libs/magick %% a

Minimum Trigger

./utilities/.libs/magick %% [any_output_filename]

Crash Analysis

AddressSanitizer Output

$ ./utilities/.libs/magick %% a
=================================================================
==2227694==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7037f99e3ad3 at pc 0x741801e81a17 bp 0x7ffd22fa4e00 sp 0x7ffd22fa45b8
READ of size 1 at 0x7037f99e3ad3 thread T0
    #0 0x741801e81a16 in strchr /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:746
    #1 0x7418013b4f06 in InterpretImageFilename MagickCore/image.c:1674
    #2 0x7418012826a3 in ReadImages MagickCore/constitute.c:1040
    #3 0x741800e4696b in CLINoImageOperator MagickWand/operation.c:4959
    #4 0x741800e64de7 in CLIOption MagickWand/operation.c:5473
    #5 0x741800d92edf in ProcessCommandOptions MagickWand/magick-cli.c:653
    #6 0x741800d94816 in MagickImageCommand MagickWand/magick-cli.c:1392
    #7 0x741800d913e4 in MagickCommandGenesis MagickWand/magick-cli.c:177
    #8 0x5ef7a3546638 in MagickMain utilities/magick.c:162
    #9 0x5ef7a3546872 in main utilities/magick.c:193
    #10 0x7417ff53f6b4  (/usr/lib/libc.so.6+0x276b4) (BuildId: 468e3585c794491a48ea75fceb9e4d6b1464fc35)
    #11 0x7417ff53f768 in __libc_start_main (/usr/lib/libc.so.6+0x27768) (BuildId: 468e3585c794491a48ea75fceb9e4d6b1464fc35)
    #12 0x5ef7a3546204 in _start (/home/kforfk/workspace/fuzz_analysis/saigen/ImageMagick/utilities/.libs/magick+0x2204) (BuildId: 96677b60628cf297eaedb3eb17b87000d29403f2)

0x7037f99e3ad3 is located 0 bytes after 3-byte region [0x7037f99e3ad0,0x7037f99e3ad3)
allocated by thread T0 here:
    #0 0x741801f20e15 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67
    #1 0x7418013e86bc in AcquireMagickMemory MagickCore/memory.c:559

SUMMARY: AddressSanitizer: heap-buffer-overflow MagickCore/image.c:1674 in InterpretImageFilename
Shadow bytes around the buggy address:
  0x7037f99e3800: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa
  0x7037f99e3880: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa
  0x7037f99e3900: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa
  0x7037f99e3980: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa
  0x7037f99e3a00: fa fa 07 fa fa fa fd fa fa fa fd fa fa fa 00 04
=>0x7037f99e3a80: fa fa 00 04 fa fa 00 00 fa fa[03]fa fa fa 03 fa
  0x7037f99e3b00: fa fa 00 01 fa fa fa fa fa fa fa fa fa fa fa fa
  0x7037f99e3b80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7037f99e3c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7037f99e3c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7037f99e3d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==2227694==ABORTING

Root Cause Analysis

The first command line argument is interpreted as MagickImageCommand: https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/utilities/magick.c#L83

const CommandInfo
  MagickCommands[] =
  {
    MagickCommandSize("magick", MagickFalse, MagickImageCommand),

It is invoked here: https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L220

status=command(image_info,argc,argv,&text,exception);

The execution then follows this path: - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L1387 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L586 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L419 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L5391 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L5473 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L4959 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/constitute.c#L1009 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/constitute.c#L1039 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/image.c#L1649 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/image.c#L1674

The execution eventually reaches InterpretImageFilename and enters a loop. The format variable here is "%%". At this point, it is safe to access *(format + 2) but not safe to access *(format + 3).

for (p=strchr(format,'%'); p != (char *) NULL; p=strchr(p+1,'%'))
{
  q=(char *) p+1;
  if (*q == '%')
    {
      p=q+1;
      continue;
    }

The first strchr call returns a pointer equal to format and assigns it to p. Then q is initialized with p + 1 (format + 1), and *q is '%', so the code enters the if branch. Here, p is reassigned to q + 1 (format + 2).

In the next iteration, p + 1 (format + 3) is passed to strchr, and when strchr accesses it, this causes an out-of-bounds read.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-AnyCPU"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-AnyCPU"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-OpenMP-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-OpenMP-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-HDRI-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-OpenMP-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-OpenMP-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q16-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-AnyCPU"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-OpenMP-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-OpenMP-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-arm64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-x64"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Magick.NET-Q8-x86"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-53014"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125",
      "CWE-193"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-25T15:53:34Z",
    "nvd_published_at": "2025-07-14T18:15:23Z",
    "severity": "LOW"
  },
  "details": "# Heap Buffer Overflow in InterpretImageFilename\n\n## Summary\nA heap buffer overflow was identified in the `InterpretImageFilename` function of ImageMagick. The issue stems from an off-by-one error that causes out-of-bounds memory access when processing format strings containing consecutive percent signs (`%%`).\n\n## Environment\n- **OS**: Arch Linux (Linux gmkhost 6.14.2-arch1-1 # 1 SMP PREEMPT_DYNAMIC Thu, 10 Apr 2025 18:43:59 +0000 x86_64 GNU/Linux (GNU libc) 2.41)\n- **Architecture**: x86_64\n- **Compiler**: gcc (GCC) 15.1.1 20250425\n\n## Reproduction\n\n### Build Instructions\n```bash\n# Clone the repository\ngit clone https://github.com/ImageMagick/ImageMagick.git\ncd ImageMagick\ngit reset --hard 8fff9b4f44d2e8b5cae2bd6db70930a144d15f12\n\n# Build with AddressSanitizer\nexport CFLAGS=\"-fsanitize=address -g -O1\"\nexport CXXFLAGS=\"-fsanitize=address -g -O1\"\nexport LDFLAGS=\"-fsanitizer=address\"\n./configure\nmake\n\n# Set library path and trigger the crash\nexport LD_LIBRARY_PATH=\"$(pwd)/MagickWand/.libs:$(pwd)/MagickCore/.libs:$LD_LIBRARY_PATH\"\n./utilities/.libs/magick %% a\n```\n\n### Minimum Trigger\n```bash\n./utilities/.libs/magick %% [any_output_filename]\n```\n\n## Crash Analysis\n\n### AddressSanitizer Output\n```\n$ ./utilities/.libs/magick %% a\n=================================================================\n==2227694==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7037f99e3ad3 at pc 0x741801e81a17 bp 0x7ffd22fa4e00 sp 0x7ffd22fa45b8\nREAD of size 1 at 0x7037f99e3ad3 thread T0\n    #0 0x741801e81a16 in strchr /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:746\n    #1 0x7418013b4f06 in InterpretImageFilename MagickCore/image.c:1674\n    #2 0x7418012826a3 in ReadImages MagickCore/constitute.c:1040\n    #3 0x741800e4696b in CLINoImageOperator MagickWand/operation.c:4959\n    #4 0x741800e64de7 in CLIOption MagickWand/operation.c:5473\n    #5 0x741800d92edf in ProcessCommandOptions MagickWand/magick-cli.c:653\n    #6 0x741800d94816 in MagickImageCommand MagickWand/magick-cli.c:1392\n    #7 0x741800d913e4 in MagickCommandGenesis MagickWand/magick-cli.c:177\n    #8 0x5ef7a3546638 in MagickMain utilities/magick.c:162\n    #9 0x5ef7a3546872 in main utilities/magick.c:193\n    #10 0x7417ff53f6b4  (/usr/lib/libc.so.6+0x276b4) (BuildId: 468e3585c794491a48ea75fceb9e4d6b1464fc35)\n    #11 0x7417ff53f768 in __libc_start_main (/usr/lib/libc.so.6+0x27768) (BuildId: 468e3585c794491a48ea75fceb9e4d6b1464fc35)\n    #12 0x5ef7a3546204 in _start (/home/kforfk/workspace/fuzz_analysis/saigen/ImageMagick/utilities/.libs/magick+0x2204) (BuildId: 96677b60628cf297eaedb3eb17b87000d29403f2)\n\n0x7037f99e3ad3 is located 0 bytes after 3-byte region [0x7037f99e3ad0,0x7037f99e3ad3)\nallocated by thread T0 here:\n    #0 0x741801f20e15 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67\n    #1 0x7418013e86bc in AcquireMagickMemory MagickCore/memory.c:559\n\nSUMMARY: AddressSanitizer: heap-buffer-overflow MagickCore/image.c:1674 in InterpretImageFilename\nShadow bytes around the buggy address:\n  0x7037f99e3800: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa\n  0x7037f99e3880: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa\n  0x7037f99e3900: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa\n  0x7037f99e3980: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa\n  0x7037f99e3a00: fa fa 07 fa fa fa fd fa fa fa fd fa fa fa 00 04\n=\u003e0x7037f99e3a80: fa fa 00 04 fa fa 00 00 fa fa[03]fa fa fa 03 fa\n  0x7037f99e3b00: fa fa 00 01 fa fa fa fa fa fa fa fa fa fa fa fa\n  0x7037f99e3b80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n  0x7037f99e3c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n  0x7037f99e3c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n  0x7037f99e3d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\nShadow byte legend (one shadow byte represents 8 application bytes):\n  Addressable:           00\n  Partially addressable: 01 02 03 04 05 06 07 \n  Heap left redzone:       fa\n  Freed heap region:       fd\n  Stack left redzone:      f1\n  Stack mid redzone:       f2\n  Stack right redzone:     f3\n  Stack after return:      f5\n  Stack use after scope:   f8\n  Global redzone:          f9\n  Global init order:       f6\n  Poisoned by user:        f7\n  Container overflow:      fc\n  Array cookie:            ac\n  Intra object redzone:    bb\n  ASan internal:           fe\n  Left alloca redzone:     ca\n  Right alloca redzone:    cb\n==2227694==ABORTING\n```\n\n## Root Cause Analysis\nThe first command line argument is interpreted as `MagickImageCommand`:\nhttps://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/utilities/magick.c#L83\n```c\nconst CommandInfo\n  MagickCommands[] =\n  {\n    MagickCommandSize(\"magick\", MagickFalse, MagickImageCommand),\n```\n\nIt is invoked here:\nhttps://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L220\n```c\nstatus=command(image_info,argc,argv,\u0026text,exception);\n```\n\nThe execution then follows this path:\n- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L1387\n- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L586\n- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L419\n- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L5391\n- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L5473\n- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L4959\n- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/constitute.c#L1009\n- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/constitute.c#L1039\n- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/image.c#L1649\n- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/image.c#L1674\n\nThe execution eventually reaches `InterpretImageFilename` and enters a loop. The `format` variable here is `\"%%\"`. At this point, it is safe to access `*(format + 2)` but not safe to access `*(format + 3)`.\n\n```c\nfor (p=strchr(format,\u0027%\u0027); p != (char *) NULL; p=strchr(p+1,\u0027%\u0027))\n{\n  q=(char *) p+1;\n  if (*q == \u0027%\u0027)\n    {\n      p=q+1;\n      continue;\n    }\n```\n\nThe first `strchr` call returns a pointer equal to `format` and assigns it to `p`. Then `q` is initialized with `p + 1` (`format + 1`), and `*q` is `\u0027%\u0027`, so the code enters the if branch. Here, `p` is reassigned to `q + 1` (`format + 2`).\n\nIn the next iteration, `p + 1` (`format + 3`) is passed to `strchr`, and when `strchr` accesses it, this causes an out-of-bounds read.",
  "id": "GHSA-hm4x-r5hc-794f",
  "modified": "2025-11-03T21:34:06Z",
  "published": "2025-08-25T15:53:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-hm4x-r5hc-794f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53014"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ImageMagick/ImageMagick/commit/29d82726c7ec20c07c49ba263bdcea16c2618e03"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ImageMagick/ImageMagick6/commit/79b6ed03770781d996d1710b89fbb887e5ea758a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ImageMagick/ImageMagick"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dlemstra/Magick.NET/releases/tag/14.7.0"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/09/msg00012.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ImageMagick has a Heap Buffer Overflow in InterpretImageFilename"
}

Mitigation
Implementation

When copying character arrays or using character manipulation methods, the correct size parameter must be used to account for the null terminator that needs to be added at the end of the array. Some examples of functions susceptible to this weakness in C include strcpy(), strncpy(), strcat(), strncat(), printf(), sprintf(), scanf() and sscanf().

No CAPEC attack patterns related to this CWE.