JLSEC-2026-812
- Source
- https://github.com/JuliaLang/SecurityAdvisories.jl/blob/main/advisories/published/2026/JLSEC-2026-812.md
- Import Source
- https://github.com/JuliaLang/SecurityAdvisories.jl/tree/generated/osv/2026/JLSEC-2026-812.json
- JSON Data
- https://api.osv.dev/v1/vulns/JLSEC-2026-812
- Upstream
- Published
- 2026-07-29T14:18:08.707Z
- Modified
- 2026-07-29T14:30:04.201582017Z
- Severity
-
- 7.1 (High) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H CVSS Calculator
- Summary
- Heap buffer overflow when decoding a malicious HTJ2K-compressed EXR file
- Details
-
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, an integer overflow in
ht_undo_impl()insrc/lib/OpenEXRCore/internal_ht.cppleads to a heap-buffer overflow when decoding a crafted HTJ2K-compressed EXR file. decode->channels[i].width (int32_t) is multiplied bybytes_per_elementin 32-bit signed arithmetic. With large widths (e.g., >= 536870912 for FLOAT data), this overflows, producing a corrupted offset that is later used for pointer arithmetic and can cause a heap out-of-bounds write. The same unchecked multiplication pattern appears in two other HTJ2K paths (bytes-per-line accumulation and pixel-line pointer advancement). As with related CVE-2026-34378 through CVE-2026-34589 fixes in other codecs, validating only after the multiplication is too late because the value may already be overflowed. This issue has been fixed in version 3.4.12. - Database specific
{ "sources": [ { "html_url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44663", "url": "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-44663", "modified": "2026-06-26T02:20:43.437Z", "id": "CVE-2026-44663", "published": "2026-06-18T21:16:28.767Z", "imported": "2026-07-29T13:22:21.154Z", "database_specific": { "status": "Analyzed" } } ], "license": "CC-BY-4.0" }- References