{"id":"CVE-2026-65979","aliases":["BELL-CVE-2026-65979","DEBIAN-CVE-2026-65979","EUVD-2026-65734","GHSA-3j9c-j7c9-x293","UBUNTU-CVE-2026-65979","openSUSE-SU-2026:11612-1"],"status":"published","title":"OpenEXR: Out-of-bounds read in HTJ2K decoder from unvalidated chunk header length (PLEN)","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. From version 3.4.0 through 3.4.12, the HTJ2K decoder parses a header-length field (PLEN) from a chunk's compressed data but never checks that this value fits within the available buffer before using it. When decoding, it advances the codestream pointer by the attacker-supplied header size and passes the resulting offset and remaining length to the OpenJPH memory-input path, so a crafted value pushes the pointer past the end of the buffer and causes an out-of-bounds read. Because this field comes straight from attacker-controlled EXR chunk data, the flaw is reachable during normal decoding of an untrusted file. This issue is fixed in version 3.4.13.","severity":{"version":"4.0","score":6.7,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.0018,"percentile":0.07692,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-125","CWE-20"],"published":"2026-08-25T18:58:25Z","modified":"2026-10-28T11:17:12Z","fixes":[{"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"]}],"affected":[{"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":"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: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.14-1.1"}]}],"bundled":17}],"products":[{"vendor":"academysoftwarefoundation","product":"openexr"}],"references":[{"url":"https://github.com/AcademySoftwareFoundation/openexr/security/advisories/GHSA-3j9c-j7c9-x293","tags":["x_refsource_CONFIRM","exploit","advisory","report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/commit/c7af2d233b7b2a4452c11f26cf47584cc2b35721","tags":["x_refsource_MISC","fix","report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.4.13","tags":["x_refsource_MISC","web"]},{"url":"https://docs.bell-sw.com/security/cves/CVE-2026-65979","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/65xxx/CVE-2026-65979.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-65979","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-65979","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2026-65979","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-65979","tags":["report"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59183","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59184","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59186","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59187","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59189","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59981","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59982","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59983","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59984","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59985","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-61555","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-61703","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-62986","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-65979","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-68513","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-68514","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-68515","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2026-65979","title":"OpenEXR: Out-of-bounds read in HTJ2K decoder from unvalidated chunk header length (PLEN)","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. From version 3.4.0 through 3.4.12, the HTJ2K decoder parses a header-length field (PLEN) from a chunk's compressed data but never checks that this value fits within the available buffer before using it. When decoding, it advances the codestream pointer by the attacker-supplied header size and passes the resulting offset and remaining length to the OpenJPH memory-input path, so a crafted value pushes the pointer past the end of the buffer and causes an out-of-bounds read. Because this field comes straight from attacker-controlled EXR chunk data, the flaw is reachable during normal decoding of an untrusted file. This issue is fixed in version 3.4.13.","status":"published","published":"2026-08-25T18:58:25.871Z","modified":"2026-08-25T19:16:25.169Z","cvss":[{"version":"4.0","score":6.7,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium","assessor":"cna"}],"cwes":["CWE-20","CWE-125"],"updated_at":"2026-11-02T13:37:13.934727Z"}],"euvd":[{"id":"EUVD-2026-65734","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. From version 3.4.0 through 3.4.12, the HTJ2K decoder parses a header-length field (PLEN) from a chunk's compressed data but never checks that this value fits within the available buffer before using it. When decoding, it advances the codestream pointer by the attacker-supplied header size and passes the resulting offset and remaining length to the OpenJPH memory-input path, so a crafted value pushes the pointer past the end of the buffer and causes an out-of-bounds read. Because this field comes straight from attacker-controlled EXR chunk data, the flaw is reachable during normal decoding of an untrusted file. This issue is fixed in version 3.4.13.","status":"published","published":"2026-08-25T18:58:25Z","modified":"2026-08-25T19:16:25Z","cvss":[{"version":"4.0","score":6.7,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T18:01:32.174502Z"}],"nvd":[{"id":"CVE-2026-65979","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. From version 3.4.0 through 3.4.12, the HTJ2K decoder parses a header-length field (PLEN) from a chunk's compressed data but never checks that this value fits within the available buffer before using it. When decoding, it advances the codestream pointer by the attacker-supplied header size and passes the resulting offset and remaining length to the OpenJPH memory-input path, so a crafted value pushes the pointer past the end of the buffer and causes an out-of-bounds read. Because this field comes straight from attacker-controlled EXR chunk data, the flaw is reachable during normal decoding of an untrusted file. This issue is fixed in version 3.4.13.","status":"published","published":"2026-08-25T19:16:52.307Z","modified":"2026-09-09T21:07:31.353Z","cvss":[{"version":"4.0","score":6.7,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium","assessor":"secondary"}],"cwes":["CWE-20","CWE-125"],"updated_at":"2026-11-02T14:12:41.347728Z"}],"osv":[{"id":"CVE-2026-65979","title":"OpenEXR: Out-of-bounds read in HTJ2K decoder from unvalidated chunk header length (PLEN)","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. From version 3.4.0 through 3.4.12, the HTJ2K decoder parses a header-length field (PLEN) from a chunk's compressed data but never checks that this value fits within the available buffer before using it. When decoding, it advances the codestream pointer by the attacker-supplied header size and passes the resulting offset and remaining length to the OpenJPH memory-input path, so a crafted value pushes the pointer past the end of the buffer and causes an out-of-bounds read. Because this field comes straight from attacker-controlled EXR chunk data, the flaw is reachable during normal decoding of an untrusted file. This issue is fixed in version 3.4.13.","status":"published","published":"2026-08-25T18:58:25.871Z","modified":"2026-10-28T11:17:12.306982658Z","cvss":[{"version":"4.0","score":6.7,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-125","CWE-20"],"updated_at":"2026-11-02T15:45:14.46177Z"},{"id":"DEBIAN-CVE-2026-65979","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. From version 3.4.0 through 3.4.12, the HTJ2K decoder parses a header-length field (PLEN) from a chunk's compressed data but never checks that this value fits within the available buffer before using it. When decoding, it advances the codestream pointer by the attacker-supplied header size and passes the resulting offset and remaining length to the OpenJPH memory-input path, so a crafted value pushes the pointer past the end of the buffer and causes an out-of-bounds read. Because this field comes straight from attacker-controlled EXR chunk data, the flaw is reachable during normal decoding of an untrusted file. This issue is fixed in version 3.4.13.","status":"published","published":"2026-08-25T19:16:52.307Z","modified":"2026-10-01T03:03:31.842921355Z","cvss":[{"version":"4.0","score":6.7,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium"}],"updated_at":"2026-11-02T15:45:58.699079Z"},{"id":"UBUNTU-CVE-2026-65979","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. From version 3.4.0 through 3.4.12, the HTJ2K decoder parses a header-length field (PLEN) from a chunk's compressed data but never checks that this value fits within the available buffer before using it. When decoding, it advances the codestream pointer by the attacker-supplied header size and passes the resulting offset and remaining length to the OpenJPH memory-input path, so a crafted value pushes the pointer past the end of the buffer and causes an out-of-bounds read. Because this field comes straight from attacker-controlled EXR chunk data, the flaw is reachable during normal decoding of an untrusted file. This issue is fixed in version 3.4.13.","status":"published","published":"2026-08-25T19:16:00Z","modified":"2026-10-17T12:56:23.904176348Z","cvss":[{"version":"4.0","score":6.7,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T16:56:53.710209Z"},{"id":"BELL-CVE-2026-65979","status":"published","published":"2026-09-03T06:05:24.59164Z","modified":"2026-09-04T07:15:09.520538734Z","updated_at":"2026-11-02T15:28:25.231222Z"},{"id":"openSUSE-SU-2026:11612-1","title":"libIex-3_4-33-3.4.14-1.1 on GA media","description":"These are all security issues fixed in the libIex-3_4-33-3.4.14-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-08-26T00:00:00Z","modified":"2026-08-27T11:01:51.561724459Z","updated_at":"2026-11-02T16:58:39.516824Z"}]}}