{"id":"CVE-2026-44663","aliases":["ALPINE-CVE-2026-44663","BELL-CVE-2026-44663","DEBIAN-CVE-2026-44663","EUVD-2026-37944","GHSA-777r-f9x8-7r84","JLSEC-2026-812","UBUNTU-CVE-2026-44663","openSUSE-SU-2026:10985-1"],"status":"published","title":"OpenEXR: Integer overflow in the HTJ2K decoder leads to heap-buffer-overflow","description":"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() in src/lib/OpenEXRCore/internal_ht.cpp leads to a heap-buffer overflow when decoding a crafted HTJ2K-compressed EXR file. decode-\u003echannels[i].width (int32_t) is multiplied by bytes_per_element in 32-bit signed arithmetic. With large widths (e.g., \u003e= 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.","severity":{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00211,"percentile":0.11531,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-190","CWE-787"],"published":"2026-06-09T00:00:00Z","modified":"2026-11-03T06:32:55Z","fixes":[{"ecosystem":"Alpine:v3.23","package":"openexr","fixed_in":["3.4.13-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.24","package":"openexr","fixed_in":["3.4.13-r0"],"sources":["osv"]},{"ecosystem":"Alpaquita:stream","package":"openexr","fixed_in":["3.4.13-r0"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"openexr","fixed_in":["3.4.14-0.1"],"sources":["osv"]},{"ecosystem":"Julia","package":"OpenEXR_jll","fixed_in":["3.4.12+0"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Alpine:v3.23","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.4.0"},{"fixed":"3.4.13-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.24","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.4.0"},{"fixed":"3.4.13-r0"}]}]},{"source":"osv","ecosystem":"Alpaquita:stream","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.4.4-r0"},{"fixed":"3.4.13-r0"}]}]},{"source":"osv","ecosystem":"Debian:14","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.4.14-0.1"}]}],"versions":["3.1.13-2","3.4.6+ds-1","3.4.6+ds-2","3.4.6+ds-3","3.4.6+ds-4"]},{"source":"osv","ecosystem":"Julia","package":"OpenEXR_jll","ranges":[{"type":"SEMVER","events":[{"introduced":"3.4.4+0"},{"fixed":"3.4.12+0"}]}]},{"source":"osv","ecosystem":"Ubuntu:Pro:16.04:LTS","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.2.0-1ubuntu3","2.2.0-7ubuntu1","2.2.0-9ubuntu1","2.2.0-10ubuntu2","2.2.0-10ubuntu2.1","2.2.0-10ubuntu2.2","2.2.0-10ubuntu2.3","2.2.0-10ubuntu2.4","2.2.0-10ubuntu2.6","2.2.0-10ubuntu2.6+esm1","2.2.0-10ubuntu2.6+esm2","2.2.0-10ubuntu2.6+esm3","2.2.0-10ubuntu2.6+esm4"]},{"source":"osv","ecosystem":"Ubuntu:Pro:18.04:LTS","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.2.0-11ubuntu1","2.2.0-11.1ubuntu1","2.2.0-11.1ubuntu1.1","2.2.0-11.1ubuntu1.2","2.2.0-11.1ubuntu1.3","2.2.0-11.1ubuntu1.4","2.2.0-11.1ubuntu1.6","2.2.0-11.1ubuntu1.7","2.2.0-11.1ubuntu1.8","2.2.0-11.1ubuntu1.9","2.2.0-11.1ubuntu1.9+esm1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:20.04:LTS","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.2.1-4.1ubuntu1","2.3.0-6","2.3.0-6build1","2.3.0-6ubuntu0.1","2.3.0-6ubuntu0.2","2.3.0-6ubuntu0.3","2.3.0-6ubuntu0.5","2.3.0-6ubuntu0.5+esm1","2.3.0-6ubuntu0.5+esm2"]},{"source":"osv","ecosystem":"Ubuntu:Pro:22.04:LTS","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.5.4-2","2.5.7-1","2.5.7-1ubuntu0.1~esm1","2.5.7-1ubuntu0.1~esm2"]},{"source":"osv","ecosystem":"Ubuntu:Pro:24.04:LTS","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.5-5.1","3.1.5-5.1build1","3.1.5-5.1build2","3.1.5-5.1build3","3.1.5-5.1ubuntu0.1~esm1"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.13-2"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.13-2build1","3.4.6+ds-4ubuntu3"]},{"source":"osv","ecosystem":"Ubuntu:Pro:26.04:LTS","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.13-2","3.1.13-2build1","3.1.13-2ubuntu0.26.04.1~esm1"]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.4.12-1.1"}]}],"bundled":2}],"products":[{"vendor":"academysoftwarefoundation","product":"openexr"},{"vendor":"openexr","product":"openexr"}],"references":[{"url":"https://github.com/AcademySoftwareFoundation/openexr/security/advisories/GHSA-777r-f9x8-7r84","tags":["x_refsource_CONFIRM","exploit","Exploit","Mitigation","Patch","Vendor Advisory","advisory","web","report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.4.12","tags":["x_refsource_MISC","Release Notes","web","report"]},{"url":"https://security.alpinelinux.org/vuln/CVE-2026-44663","tags":["advisory"]},{"url":"https://docs.bell-sw.com/security/cves/CVE-2026-44663","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/44xxx/CVE-2026-44663.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-44663","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-44663","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2026-44663","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-44663","tags":["report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/pull/2403","tags":["report"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44663","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-45696","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2026-44663","title":"OpenEXR: Integer overflow in the HTJ2K decoder leads to heap-buffer-overflow","description":"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() in src/lib/OpenEXRCore/internal_ht.cpp leads to a heap-buffer overflow when decoding a crafted HTJ2K-compressed EXR file. decode-\u003echannels[i].width (int32_t) is multiplied by bytes_per_element in 32-bit signed arithmetic. With large widths (e.g., \u003e= 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.","status":"published","published":"2026-06-18T20:20:15.532Z","modified":"2026-06-22T15:47:32.968Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"medium","assessor":"cna"}],"cwes":["CWE-190","CWE-787"],"updated_at":"2026-11-02T13:43:00.288193Z"}],"euvd":[{"id":"EUVD-2026-37944","description":"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() in src/lib/OpenEXRCore/internal_ht.cpp leads to a heap-buffer overflow when decoding a crafted HTJ2K-compressed EXR file. decode-\u003echannels[i].width (int32_t) is multiplied by bytes_per_element in 32-bit signed arithmetic. With large widths (e.g., \u003e= 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.","status":"published","published":"2026-06-18T20:20:15Z","modified":"2026-06-22T15:47:32Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"medium"}],"updated_at":"2026-11-02T18:20:34.745289Z"}],"nvd":[{"id":"CVE-2026-44663","description":"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() in src/lib/OpenEXRCore/internal_ht.cpp leads to a heap-buffer overflow when decoding a crafted HTJ2K-compressed EXR file. decode-\u003echannels[i].width (int32_t) is multiplied by bytes_per_element in 32-bit signed arithmetic. With large widths (e.g., \u003e= 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.","status":"published","published":"2026-06-18T21:16:28.767Z","modified":"2026-10-26T11:10:00.157Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"medium","assessor":"secondary"},{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H","level":"high","assessor":"primary"}],"cwes":["CWE-190","CWE-787"],"updated_at":"2026-11-02T14:12:24.912854Z"}],"osv":[{"id":"ALPINE-CVE-2026-44663","description":"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() in src/lib/OpenEXRCore/internal_ht.cpp leads to a heap-buffer overflow when decoding a crafted HTJ2K-compressed EXR file. decode-\u003echannels[i].width (int32_t) is multiplied by bytes_per_element in 32-bit signed arithmetic. With large widths (e.g., \u003e= 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.","status":"published","published":"2026-06-18T21:16:28.767Z","modified":"2026-11-03T06:32:55.782552616Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H","level":"high"}],"updated_at":"2026-11-03T07:16:26.770911Z"},{"id":"BELL-CVE-2026-44663","status":"published","published":"2026-06-20T06:11:21.358658Z","modified":"2026-07-24T07:15:06.458058989Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:28:24.12174Z"},{"id":"CVE-2026-44663","title":"OpenEXR: Integer overflow in the HTJ2K decoder leads to heap-buffer-overflow","description":"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() in src/lib/OpenEXRCore/internal_ht.cpp leads to a heap-buffer overflow when decoding a crafted HTJ2K-compressed EXR file. decode-\u003echannels[i].width (int32_t) is multiplied by bytes_per_element in 32-bit signed arithmetic. With large widths (e.g., \u003e= 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.","status":"published","published":"2026-06-18T20:20:15.532Z","modified":"2026-10-28T02:30:58.306763483Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"medium"}],"cwes":["CWE-190","CWE-787"],"updated_at":"2026-11-02T15:45:05.172514Z"},{"id":"DEBIAN-CVE-2026-44663","description":"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() in src/lib/OpenEXRCore/internal_ht.cpp leads to a heap-buffer overflow when decoding a crafted HTJ2K-compressed EXR file. decode-\u003echannels[i].width (int32_t) is multiplied by bytes_per_element in 32-bit signed arithmetic. With large widths (e.g., \u003e= 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.","status":"published","published":"2026-06-18T21:16:28.767Z","modified":"2026-10-27T09:47:41.021266838Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:45:55.669088Z"},{"id":"JLSEC-2026-812","title":"Heap buffer overflow when decoding a malicious HTJ2K-compressed EXR file","description":"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()` in `src/lib/OpenEXRCore/internal_ht.cpp` leads to a heap-buffer overflow when decoding a crafted HTJ2K-compressed EXR file. decode-\u003echannels[i].width (`int32_t`) is multiplied by `bytes_per_element` in 32-bit signed arithmetic. With large widths (e.g., \u003e= 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.","status":"published","published":"2026-07-29T14:18:08.707Z","modified":"2026-07-29T14:30:04.201582017Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:47:19.003546Z"},{"id":"UBUNTU-CVE-2026-44663","description":"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() in src/lib/OpenEXRCore/internal_ht.cpp leads to a heap-buffer overflow when decoding a crafted HTJ2K-compressed EXR file. decode-\u003echannels[i].width (int32_t) is multiplied by bytes_per_element in 32-bit signed arithmetic. With large widths (e.g., \u003e= 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.","status":"published","published":"2026-06-18T21:16:00Z","modified":"2026-10-17T12:58:20.86317929Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"medium"},{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T16:56:26.396868Z"},{"id":"openSUSE-SU-2026:10985-1","title":"libIex-3_4-33-3.4.12-1.1 on GA media","description":"These are all security issues fixed in the libIex-3_4-33-3.4.12-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-06-09T00:00:00Z","modified":"2026-06-10T18:24:13.932644962Z","updated_at":"2026-11-02T16:58:38.95195Z"}]}}