{"id":"CVE-2026-34379","aliases":["ALPINE-CVE-2026-34379","BELL-CVE-2026-34379","DEBIAN-CVE-2026-34379","EUVD-2026-19305","GHSA-w88v-vqhq-5p24","JLSEC-2026-143","OESA-2026-1840","OESA-2026-1841","OESA-2026-1842","OESA-2026-1843","ROOT-OS-DEBIAN-11-CVE-2026-34379","ROOT-OS-DEBIAN-12-CVE-2026-34379","ROOT-OS-DEBIAN-13-CVE-2026-34379","SUSE-SU-2026:21372-1","UBUNTU-CVE-2026-34379","openSUSE-SU-2026:10505-1","openSUSE-SU-2026:20605-1"],"status":"published","title":"OpenEXR has a misaligned write in LossyDctDecoder_execute leading to undefined behavior (DWA/DWAB decompression)","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.","severity":{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00294,"percentile":0.22328,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-475","CWE-704","CWE-787","CWE-843"],"published":"2026-04-06T15:21:06Z","modified":"2026-11-11T07:00:20Z","fixes":[{"ecosystem":"Alpine:v3.22","package":"openexr","fixed_in":["3.3.11-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.23","package":"openexr","fixed_in":["3.4.13-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.24","package":"openexr","fixed_in":["3.4.10-r0"],"sources":["osv"]},{"ecosystem":"Alpaquita:stream","package":"openexr","fixed_in":["3.4.9-r0"],"sources":["osv"]},{"ecosystem":"Debian:13","package":"openexr","fixed_in":["3.2.12-1~deb13u1"],"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.9+0"],"sources":["osv"]},{"ecosystem":"Root:Debian:11","package":"openexr","fixed_in":["2.5.4-2+deb11u1.root.io.14","2.5.4-2+deb11u1.aikido.17","2.5.4-2+deb11u1.aikido.16","2.5.4-2+deb11u1.root.io.15","2.5.4-2+deb11u1.aikido.18"],"sources":["osv"]},{"ecosystem":"Root:Debian:11","package":"rootio-openexr","fixed_in":["2.5.4-2+deb11u1.root.io.14","2.5.4-2+deb11u1.aikido.17","2.5.4-2+deb11u1.aikido.16","2.5.4-2+deb11u1.root.io.15","2.5.4-2+deb11u1.aikido.18"],"sources":["osv"]},{"ecosystem":"Root:Debian:12","package":"openexr","fixed_in":["3.1.5-5.root.io.15","3.1.5-5.root.io.21","3.1.5-5.root.io.22","3.1.5-5.root.io.23","3.1.5-5.root.io.14","3.1.5-5.root.io.16","3.1.5-5.root.io.17","3.1.5-5.root.io.18","3.1.5-5.root.io.19","3.1.5-5.root.io.20","3.1.5-5.aikido.24","3.1.5-5.aikido.25"],"sources":["osv"]},{"ecosystem":"Root:Debian:12","package":"rootio-openexr","fixed_in":["3.1.5-5.root.io.15","3.1.5-5.root.io.21","3.1.5-5.root.io.22","3.1.5-5.root.io.23","3.1.5-5.root.io.14","3.1.5-5.root.io.16","3.1.5-5.root.io.17","3.1.5-5.root.io.18","3.1.5-5.root.io.19","3.1.5-5.root.io.20","3.1.5-5.aikido.24","3.1.5-5.aikido.25"],"sources":["osv"]},{"ecosystem":"Root:Debian:13","package":"openexr","fixed_in":["3.1.13-2.aikido.14","3.1.13-2.root.io.11","3.1.13-2.root.io.13","3.1.13-2.root.io.12","3.1.13-2.aikido.15"],"sources":["osv"]},{"ecosystem":"Root:Debian:13","package":"rootio-openexr","fixed_in":["3.1.13-2.aikido.14","3.1.13-2.root.io.11","3.1.13-2.root.io.13","3.1.13-2.root.io.12","3.1.13-2.aikido.15"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Alpine:v3.22","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.2.0"},{"fixed":"3.3.11-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.23","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.2.0"},{"fixed":"3.4.13-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.24","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.2.0"},{"fixed":"3.4.10-r0"}]}]},{"source":"osv","ecosystem":"Alpaquita:stream","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.4.4-r0"},{"fixed":"3.4.9-r0"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.13-1","3.1.13-2","3.1.5-5","3.1.5-5.1","3.1.5-5.1+hurd.1","3.2.12-1~deb13u1","3.4.14-0.1","3.4.15+ds-1","3.4.16+ds-1","3.4.6+ds-1","3.4.6+ds-2","3.4.6+ds-3","3.4.6+ds-4","3.5.2+ds-1"]},{"source":"osv","ecosystem":"Debian:13","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.2.12-1~deb13u1"}]}],"versions":["3.1.13-2"]},{"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.2.12-1~deb13u1","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.1.4+0"},{"fixed":"3.4.9+0"}]}]},{"source":"osv","ecosystem":"openEuler:24.03-LTS","package":"OpenEXR","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.11-7.oe2403"}]}],"bundled":4},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP1","package":"OpenEXR","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.11-7.oe2403sp1"}]}],"bundled":4},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP2","package":"OpenEXR","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.11-7.oe2403sp2"}]}],"bundled":4},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP3","package":"OpenEXR","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.11-7.oe2403sp3"}]}],"bundled":4},{"source":"osv","ecosystem":"Root:Debian:11","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.4-2+deb11u1.root.io.14"},{"fixed":"2.5.4-2+deb11u1.aikido.17"},{"fixed":"2.5.4-2+deb11u1.aikido.16"},{"fixed":"2.5.4-2+deb11u1.root.io.15"},{"fixed":"2.5.4-2+deb11u1.aikido.18"}]}]},{"source":"osv","ecosystem":"Root:Debian:11","package":"rootio-openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.4-2+deb11u1.root.io.14"},{"fixed":"2.5.4-2+deb11u1.aikido.17"},{"fixed":"2.5.4-2+deb11u1.aikido.16"},{"fixed":"2.5.4-2+deb11u1.root.io.15"},{"fixed":"2.5.4-2+deb11u1.aikido.18"}]}]},{"source":"osv","ecosystem":"Root:Debian:12","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.5-5.root.io.15"},{"fixed":"3.1.5-5.root.io.21"},{"fixed":"3.1.5-5.root.io.22"},{"fixed":"3.1.5-5.root.io.23"},{"fixed":"3.1.5-5.root.io.14"},{"fixed":"3.1.5-5.root.io.16"},{"fixed":"3.1.5-5.root.io.17"},{"fixed":"3.1.5-5.root.io.18"},{"fixed":"3.1.5-5.root.io.19"},{"fixed":"3.1.5-5.root.io.20"},{"fixed":"3.1.5-5.aikido.24"},{"fixed":"3.1.5-5.aikido.25"}]}]},{"source":"osv","ecosystem":"Root:Debian:12","package":"rootio-openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.5-5.root.io.15"},{"fixed":"3.1.5-5.root.io.21"},{"fixed":"3.1.5-5.root.io.22"},{"fixed":"3.1.5-5.root.io.23"},{"fixed":"3.1.5-5.root.io.14"},{"fixed":"3.1.5-5.root.io.16"},{"fixed":"3.1.5-5.root.io.17"},{"fixed":"3.1.5-5.root.io.18"},{"fixed":"3.1.5-5.root.io.19"},{"fixed":"3.1.5-5.root.io.20"},{"fixed":"3.1.5-5.aikido.24"},{"fixed":"3.1.5-5.aikido.25"}]}]},{"source":"osv","ecosystem":"Root:Debian:13","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.13-2.aikido.14"},{"fixed":"3.1.13-2.root.io.11"},{"fixed":"3.1.13-2.root.io.13"},{"fixed":"3.1.13-2.root.io.12"},{"fixed":"3.1.13-2.aikido.15"}]}]},{"source":"osv","ecosystem":"Root:Debian:13","package":"rootio-openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.13-2.aikido.14"},{"fixed":"3.1.13-2.root.io.11"},{"fixed":"3.1.13-2.root.io.13"},{"fixed":"3.1.13-2.root.io.12"},{"fixed":"3.1.13-2.aikido.15"}]}]},{"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":"openSUSE:Tumbleweed","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.4.9-1.1"}]}],"bundled":8},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.2.2-160000.6.1"}]}],"bundled":4}],"products":[{"vendor":"academysoftwarefoundation","product":"openexr"},{"vendor":"openexr","product":"openexr"},{"vendor":"red hat","product":"red hat enterprise linux 10"},{"vendor":"red hat","product":"red hat enterprise linux 6"},{"vendor":"red hat","product":"red hat enterprise linux 7"},{"vendor":"red hat","product":"red hat enterprise linux 8"},{"vendor":"red hat","product":"red hat enterprise linux 9"}],"references":[{"url":"https://github.com/AcademySoftwareFoundation/openexr/security/advisories/GHSA-w88v-vqhq-5p24","tags":["x_refsource_CONFIRM","Exploit","Vendor Advisory","advisory","web","report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.2.7","tags":["x_refsource_MISC","Product","Release Notes","web","report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.3.9","tags":["x_refsource_MISC","Product","Release Notes","web","report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.4.9","tags":["x_refsource_MISC","Product","Release Notes","web","report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-34379","tags":["vdb-entry","x_refsource_REDHAT","advisory","web"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2455402","tags":["issue-tracking","x_refsource_REDHAT","report","web"]},{"url":"https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-34379.json","tags":["x_sadp-csaf-vex","web"]},{"url":"https://security.alpinelinux.org/vuln/CVE-2026-34379","tags":["advisory"]},{"url":"https://docs.bell-sw.com/security/cves/CVE-2026-34379","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/34xxx/CVE-2026-34379.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34379","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-34379","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1840","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34380","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34588","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34589","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1841","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1842","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1843","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202621372-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1261621","tags":["report"]},{"url":"https://bugzilla.suse.com/1261622","tags":["report"]},{"url":"https://bugzilla.suse.com/1261624","tags":["report"]},{"url":"https://bugzilla.suse.com/1261634","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34379","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34380","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34588","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34589","tags":["web"]},{"url":"https://ubuntu.com/security/CVE-2026-34379","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-34379","tags":["report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/pull/2324","tags":["report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/commit/3ad9b29430f9c2599dad113e1efe619a6ec7ba67","tags":["report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/commit/d32ffe9d3727c0474b63e91556baf61ced3d89e0","tags":["report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/commit/76af7d7508819a477f2cbce808ee975da8053ce3","tags":["report"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34378","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34543","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34544","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34545","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2026-34379","title":"OpenEXR has a misaligned write in LossyDctDecoder_execute leading to undefined behavior (DWA/DWAB decompression)","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.","status":"published","published":"2026-04-06T15:21:06.556Z","modified":"2026-07-15T01:04:28.373Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high","assessor":"cna"},{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high","assessor":"adp"}],"cwes":["CWE-704","CWE-787","CWE-843","CWE-475"],"updated_at":"2026-11-02T14:20:14.665567Z"}],"euvd":[{"id":"EUVD-2026-19305","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.","status":"published","published":"2026-04-06T15:21:06Z","modified":"2026-07-15T01:04:28Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high"}],"updated_at":"2026-11-02T18:19:56.47701Z"}],"nvd":[{"id":"CVE-2026-34379","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.","status":"published","published":"2026-04-06T16:16:35.233Z","modified":"2026-10-26T22:10:00.163Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high","assessor":"secondary"},{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-704","CWE-787","CWE-843","CWE-475"],"updated_at":"2026-11-02T14:12:13.1424Z"}],"osv":[{"id":"ALPINE-CVE-2026-34379","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.","status":"published","published":"2026-04-06T16:16:35.233Z","modified":"2026-11-03T06:32:54.884428019Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high"}],"updated_at":"2026-11-03T07:16:26.770911Z"},{"id":"BELL-CVE-2026-34379","status":"published","published":"2026-04-07T06:09:09.39218Z","modified":"2026-04-09T07:20:31.496962Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high"}],"updated_at":"2026-11-02T15:28:23.572955Z"},{"id":"CVE-2026-34379","title":"OpenEXR has a misaligned write in LossyDctDecoder_execute leading to undefined behavior (DWA/DWAB decompression)","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.","status":"published","published":"2026-04-06T15:21:06.556Z","modified":"2026-10-28T02:30:53.515370997Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high"}],"cwes":["CWE-704","CWE-787","CWE-843"],"updated_at":"2026-11-02T15:45:02.247031Z"},{"id":"DEBIAN-CVE-2026-34379","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.","status":"published","published":"2026-04-06T16:16:35.233Z","modified":"2026-11-11T07:00:20.984245437Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high"}],"updated_at":"2026-11-11T07:25:41.918486Z"},{"id":"JLSEC-2026-143","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in `LossyDctDecoder_execute()` in `src/lib/OpenEXRCore/internal_dwa_decoder.h:749`. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned `uint8_t` * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.","status":"published","published":"2026-04-17T15:19:54.657Z","modified":"2026-07-25T18:23:55.436944892Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high"}],"updated_at":"2026-11-02T15:47:18.159338Z"},{"id":"OESA-2026-1840","title":"OpenEXR security update","description":"OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light \u0026amp;amp; Magic for use in computer imaging applications.\r\n\r\nSecurity Fix(es):\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34379)\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a signed integer overflow exists in undo_pxr24_impl() in src/lib/OpenEXRCore/internal_pxr24.c at line 377. The expression (uint64_t)(w * 3) computes w * 3 as a signed 32-bit integer before casting to uint64_t. When w is large, this multiplication constitutes undefined behavior under the C standard. On tested builds (clang/gcc without sanitizers), two\u0026apos;s-complement wraparound commonly occurs, and for specific values of w the wrapped result is a small positive integer, which may allow the subsequent bounds check to pass incorrectly. If the check is bypassed, the decoding loop proceeds to write pixel data through dout, potentially extending far beyond the allocated output buffer. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34380)\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.1.0 to before 3.2.7, 3.3.9, and 3.4.9, internal_exr_undo_piz() advances the working wavelet pointer with signed 32-bit arithmetic. Because nx, ny, and wcount are int, a crafted EXR file can make this product overflow and wrap. The next channel then decodes from an incorrect address. The wavelet decode path operates in place, so this yields both out-of-bounds reads and out-of-bounds writes. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34588)\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, the DWA lossy decoder constructs temporary per-component block pointers using signed 32-bit arithmetic. For a large enough width, the calculation overflows and later decoder stores operate on a wrapped pointer outside the allocated rowBlock backing store. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34589)","status":"published","published":"2026-04-11T11:10:51Z","modified":"2026-08-18T01:19:45.862772708Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:46.087701Z"},{"id":"OESA-2026-1841","title":"OpenEXR security update","description":"OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light \u0026amp;amp; Magic for use in computer imaging applications.\r\n\r\nSecurity Fix(es):\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34379)\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a signed integer overflow exists in undo_pxr24_impl() in src/lib/OpenEXRCore/internal_pxr24.c at line 377. The expression (uint64_t)(w * 3) computes w * 3 as a signed 32-bit integer before casting to uint64_t. When w is large, this multiplication constitutes undefined behavior under the C standard. On tested builds (clang/gcc without sanitizers), two\u0026apos;s-complement wraparound commonly occurs, and for specific values of w the wrapped result is a small positive integer, which may allow the subsequent bounds check to pass incorrectly. If the check is bypassed, the decoding loop proceeds to write pixel data through dout, potentially extending far beyond the allocated output buffer. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34380)\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.1.0 to before 3.2.7, 3.3.9, and 3.4.9, internal_exr_undo_piz() advances the working wavelet pointer with signed 32-bit arithmetic. Because nx, ny, and wcount are int, a crafted EXR file can make this product overflow and wrap. The next channel then decodes from an incorrect address. The wavelet decode path operates in place, so this yields both out-of-bounds reads and out-of-bounds writes. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34588)\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, the DWA lossy decoder constructs temporary per-component block pointers using signed 32-bit arithmetic. For a large enough width, the calculation overflows and later decoder stores operate on a wrapped pointer outside the allocated rowBlock backing store. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34589)","status":"published","published":"2026-04-11T11:10:51Z","modified":"2026-08-18T01:19:47.022098631Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:46.087701Z"},{"id":"OESA-2026-1842","title":"OpenEXR security update","description":"OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light \u0026amp;amp; Magic for use in computer imaging applications.\r\n\r\nSecurity Fix(es):\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34379)\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a signed integer overflow exists in undo_pxr24_impl() in src/lib/OpenEXRCore/internal_pxr24.c at line 377. The expression (uint64_t)(w * 3) computes w * 3 as a signed 32-bit integer before casting to uint64_t. When w is large, this multiplication constitutes undefined behavior under the C standard. On tested builds (clang/gcc without sanitizers), two\u0026apos;s-complement wraparound commonly occurs, and for specific values of w the wrapped result is a small positive integer, which may allow the subsequent bounds check to pass incorrectly. If the check is bypassed, the decoding loop proceeds to write pixel data through dout, potentially extending far beyond the allocated output buffer. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34380)\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.1.0 to before 3.2.7, 3.3.9, and 3.4.9, internal_exr_undo_piz() advances the working wavelet pointer with signed 32-bit arithmetic. Because nx, ny, and wcount are int, a crafted EXR file can make this product overflow and wrap. The next channel then decodes from an incorrect address. The wavelet decode path operates in place, so this yields both out-of-bounds reads and out-of-bounds writes. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34588)\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, the DWA lossy decoder constructs temporary per-component block pointers using signed 32-bit arithmetic. For a large enough width, the calculation overflows and later decoder stores operate on a wrapped pointer outside the allocated rowBlock backing store. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34589)","status":"published","published":"2026-04-11T11:10:51Z","modified":"2026-08-18T01:19:45.920336254Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:46.087701Z"},{"id":"OESA-2026-1843","title":"OpenEXR security update","description":"OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light \u0026amp;amp; Magic for use in computer imaging applications.\r\n\r\nSecurity Fix(es):\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34379)\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a signed integer overflow exists in undo_pxr24_impl() in src/lib/OpenEXRCore/internal_pxr24.c at line 377. The expression (uint64_t)(w * 3) computes w * 3 as a signed 32-bit integer before casting to uint64_t. When w is large, this multiplication constitutes undefined behavior under the C standard. On tested builds (clang/gcc without sanitizers), two\u0026apos;s-complement wraparound commonly occurs, and for specific values of w the wrapped result is a small positive integer, which may allow the subsequent bounds check to pass incorrectly. If the check is bypassed, the decoding loop proceeds to write pixel data through dout, potentially extending far beyond the allocated output buffer. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34380)\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.1.0 to before 3.2.7, 3.3.9, and 3.4.9, internal_exr_undo_piz() advances the working wavelet pointer with signed 32-bit arithmetic. Because nx, ny, and wcount are int, a crafted EXR file can make this product overflow and wrap. The next channel then decodes from an incorrect address. The wavelet decode path operates in place, so this yields both out-of-bounds reads and out-of-bounds writes. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34588)\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, the DWA lossy decoder constructs temporary per-component block pointers using signed 32-bit arithmetic. For a large enough width, the calculation overflows and later decoder stores operate on a wrapped pointer outside the allocated rowBlock backing store. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34589)","status":"published","published":"2026-04-11T11:10:51Z","modified":"2026-08-18T01:19:47.058802697Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:46.087701Z"},{"id":"ROOT-OS-DEBIAN-11-CVE-2026-34379","title":"CVE-2026-34379 in openexr - Patched by Root","description":"Root has patched CVE-2026-34379 in the openexr package for Root:Debian:11. Multiple fixed versions available.","status":"published","published":"2026-09-02T12:13:16Z","modified":"2026-09-02T14:00:03.40132917Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high"}],"updated_at":"2026-11-02T15:53:29.900552Z"},{"id":"ROOT-OS-DEBIAN-12-CVE-2026-34379","title":"CVE-2026-34379 in openexr - Patched by Root","description":"Root has patched CVE-2026-34379 in the openexr package for Root:Debian:12. Multiple fixed versions available.","status":"published","published":"2026-09-02T11:23:23Z","modified":"2026-09-02T12:30:05.997749902Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high"}],"updated_at":"2026-11-02T15:53:32.037361Z"},{"id":"ROOT-OS-DEBIAN-13-CVE-2026-34379","title":"CVE-2026-34379 in openexr - Patched by Root","description":"Root has patched CVE-2026-34379 in the openexr package for Root:Debian:13. Multiple fixed versions available.","status":"published","published":"2026-09-02T12:18:43Z","modified":"2026-09-02T14:00:07.432798913Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high"}],"updated_at":"2026-11-02T15:53:33.415244Z"},{"id":"UBUNTU-CVE-2026-34379","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.","status":"published","published":"2026-04-06T16:16:00Z","modified":"2026-10-17T13:00:00.842697731Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high"},{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"high"}],"updated_at":"2026-11-02T16:56:16.036833Z"},{"id":"openSUSE-SU-2026:10505-1","title":"libIex-3_4-33-3.4.9-1.1 on GA media","description":"These are all security issues fixed in the libIex-3_4-33-3.4.9-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-04-08T00:00:00Z","modified":"2026-04-09T08:00:37.097659Z","updated_at":"2026-11-02T16:58:38.415593Z"},{"id":"openSUSE-SU-2026:20605-1","title":"Security update for openexr","description":"This update for openexr fixes the following issues:\n\n- CVE-2026-34379: misaligned memory write during file decoding can cause a denial of service (bsc#1261621).\n- CVE-2026-34380: lack of proper check can lead to integer overflow in image decoding (bsc#1261622).\n- CVE-2026-34588: crafted EXR file can lead to out of bound read and write (bsc#1261624).\n- CVE-2026-34589: crafted scanline DWAA file can lead to arbitrary code execution or denial of service (bsc#1261634).\n","status":"published","published":"2026-04-22T10:03:51Z","modified":"2026-04-24T08:15:58.193379Z","updated_at":"2026-11-02T16:58:41.463445Z"},{"id":"SUSE-SU-2026:21372-1","title":"Security update for openexr","description":"This update for openexr fixes the following issues:\n\n- CVE-2026-34379: misaligned memory write during file decoding can cause a denial of service (bsc#1261621).\n- CVE-2026-34380: lack of proper check can lead to integer overflow in image decoding (bsc#1261622).\n- CVE-2026-34588: crafted EXR file can lead to out of bound read and write (bsc#1261624).\n- CVE-2026-34589: crafted scanline DWAA file can lead to arbitrary code execution or denial of service (bsc#1261634).\n","status":"published","published":"2026-04-22T10:07:59Z","modified":"2026-04-29T18:23:57.798743Z","updated_at":"2026-11-02T15:54:02.312556Z"}]}}