{"id":"CVE-2025-64181","aliases":["CLSA-2026-1775211239","DEBIAN-CVE-2025-64181","EUVD-2025-50828","GHSA-3h9h-qfvw-98hq","OESA-2025-2710","OESA-2025-2711","OESA-2025-2712","OESA-2025-2713","OESA-2025-2740","PYSEC-2026-2843","ROOT-OS-DEBIAN-12-CVE-2025-64181","ROOT-OS-DEBIAN-13-CVE-2025-64181","SUSE-SU-2025:21014-1","UBUNTU-CVE-2025-64181","openSUSE-SU-2025:15741-1","openSUSE-SU-2025:20056-1"],"status":"published","title":"OpenEXR Makes Use of Uninitialized Memory","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.5 and 3.4.0 through 3.4.2, while fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory. The issue can result in undefined behavior and/or a potential crash/denial of service. Versions 3.3.6 and 3.4.3 fix the issue.","severity":{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P","level":"low","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00409,"percentile":0.35495,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-457"],"published":"2025-11-10T21:23:04Z","modified":"2026-10-28T02:30:26Z","fixes":[{"ecosystem":"PyPI","package":"openexr","fixed_in":["3.3.6","3.4.3"],"sources":["ghsa","osv"]},{"ecosystem":"Debian:14","package":"openexr","fixed_in":["3.4.6+ds-1"],"sources":["osv"]},{"ecosystem":"openEuler:22.03-LTS-SP4","package":"OpenEXR","fixed_in":["3.1.5-4.oe2203sp4"],"sources":["osv"]},{"ecosystem":"openEuler:24.03-LTS","package":"OpenEXR","fixed_in":["3.1.11-4.oe2403"],"sources":["osv"]},{"ecosystem":"openEuler:24.03-LTS-SP1","package":"OpenEXR","fixed_in":["3.1.11-4.oe2403sp1"],"sources":["osv"]},{"ecosystem":"openEuler:24.03-LTS-SP2","package":"OpenEXR","fixed_in":["3.1.11-4.oe2403sp2"],"sources":["osv"]},{"ecosystem":"openEuler:22.03-LTS-SP3","package":"OpenEXR","fixed_in":["3.1.5-4.oe2203sp3"],"sources":["osv"]},{"ecosystem":"Root:Debian:12","package":"openexr","fixed_in":["3.1.5-5.root.io.8","3.1.5-5.root.io.9","3.1.5-5.root.io.10","3.1.5-5.root.io.7","3.1.5-5.root.io.15","3.1.5-5.root.io.6","3.1.5-5.root.io.21","3.1.5-5.root.io.22","3.1.5-5.root.io.12","3.1.5-5.root.io.23","3.1.5-5.root.io.13","3.1.5-5.root.io.14","3.1.5-5.root.io.11","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.8","3.1.5-5.root.io.9","3.1.5-5.root.io.10","3.1.5-5.root.io.7","3.1.5-5.root.io.15","3.1.5-5.root.io.6","3.1.5-5.root.io.21","3.1.5-5.root.io.22","3.1.5-5.root.io.12","3.1.5-5.root.io.23","3.1.5-5.root.io.13","3.1.5-5.root.io.14","3.1.5-5.root.io.11","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.root.io.6","3.1.13-2.root.io.7","3.1.13-2.root.io.5","3.1.13-2.root.io.8","3.1.13-2.aikido.14","3.1.13-2.root.io.10","3.1.13-2.root.io.11","3.1.13-2.root.io.9","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.root.io.6","3.1.13-2.root.io.7","3.1.13-2.root.io.5","3.1.13-2.root.io.8","3.1.13-2.aikido.14","3.1.13-2.root.io.10","3.1.13-2.root.io.11","3.1.13-2.root.io.9","3.1.13-2.root.io.13","3.1.13-2.root.io.12","3.1.13-2.aikido.15"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"openexr","fixed_in":["3.2.2-160000.3.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"openexr","fixed_in":["3.2.2-160000.3.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap 16.0","package":"openexr","fixed_in":["3.2.2-160000.3.1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.3.0"},{"fixed":"3.3.6"}]}]},{"source":"ghsa","ecosystem":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.4.0"},{"fixed":"3.4.3"}]}]},{"source":"osv","ecosystem":"TuxCare:AlmaLinux:9.6","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.1-3.el9.tuxcare.els2"}]}],"bundled":4},{"source":"osv","ecosystem":"TuxCare:AlmaLinux:9.6","package":"openexr-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.1-3.el9.tuxcare.els2"}]}],"bundled":4},{"source":"osv","ecosystem":"TuxCare:AlmaLinux:9.6","package":"openexr-libs","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.1-3.el9.tuxcare.els2"}]}],"bundled":4},{"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.4.14-0.1","3.4.6+ds-1","3.4.6+ds-2","3.4.6+ds-3","3.4.6+ds-4"]},{"source":"osv","ecosystem":"Debian:13","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.13-2","3.4.14-0.1","3.4.6+ds-1","3.4.6+ds-2","3.4.6+ds-3","3.4.6+ds-4"]},{"source":"osv","ecosystem":"Debian:14","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.4.6+ds-1"}]}],"versions":["3.1.13-2"]},{"source":"osv","ecosystem":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.3.0"},{"fixed":"3.3.6"}]}],"versions":["3.3.0","3.3.1","3.3.2","3.3.3","3.3.4","3.3.5"]},{"source":"osv","ecosystem":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.4.0"},{"fixed":"3.4.3"}]}],"versions":["3.4.0","3.4.1","3.4.2"]},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP4","package":"OpenEXR","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.5-4.oe2203sp4"}]}]},{"source":"osv","ecosystem":"openEuler:24.03-LTS","package":"OpenEXR","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.11-4.oe2403"}]}]},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP1","package":"OpenEXR","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.11-4.oe2403sp1"}]}]},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP2","package":"OpenEXR","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.11-4.oe2403sp2"}]}]},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP3","package":"OpenEXR","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.5-4.oe2203sp3"}]}]},{"source":"osv","ecosystem":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.3.0"},{"fixed":"3.3.6"},{"introduced":"3.4.0"},{"fixed":"3.4.3"}]}],"versions":["3.3.0","3.3.1","3.3.2","3.3.3","3.3.4","3.3.5","3.4.0","3.4.1","3.4.2"]},{"source":"osv","ecosystem":"Root:Debian:12","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.5-5.root.io.8"},{"fixed":"3.1.5-5.root.io.9"},{"fixed":"3.1.5-5.root.io.10"},{"fixed":"3.1.5-5.root.io.7"},{"fixed":"3.1.5-5.root.io.15"},{"fixed":"3.1.5-5.root.io.6"},{"fixed":"3.1.5-5.root.io.21"},{"fixed":"3.1.5-5.root.io.22"},{"fixed":"3.1.5-5.root.io.12"},{"fixed":"3.1.5-5.root.io.23"},{"fixed":"3.1.5-5.root.io.13"},{"fixed":"3.1.5-5.root.io.14"},{"fixed":"3.1.5-5.root.io.11"},{"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.8"},{"fixed":"3.1.5-5.root.io.9"},{"fixed":"3.1.5-5.root.io.10"},{"fixed":"3.1.5-5.root.io.7"},{"fixed":"3.1.5-5.root.io.15"},{"fixed":"3.1.5-5.root.io.6"},{"fixed":"3.1.5-5.root.io.21"},{"fixed":"3.1.5-5.root.io.22"},{"fixed":"3.1.5-5.root.io.12"},{"fixed":"3.1.5-5.root.io.23"},{"fixed":"3.1.5-5.root.io.13"},{"fixed":"3.1.5-5.root.io.14"},{"fixed":"3.1.5-5.root.io.11"},{"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.root.io.6"},{"fixed":"3.1.13-2.root.io.7"},{"fixed":"3.1.13-2.root.io.5"},{"fixed":"3.1.13-2.root.io.8"},{"fixed":"3.1.13-2.aikido.14"},{"fixed":"3.1.13-2.root.io.10"},{"fixed":"3.1.13-2.root.io.11"},{"fixed":"3.1.13-2.root.io.9"},{"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.root.io.6"},{"fixed":"3.1.13-2.root.io.7"},{"fixed":"3.1.13-2.root.io.5"},{"fixed":"3.1.13-2.root.io.8"},{"fixed":"3.1.13-2.aikido.14"},{"fixed":"3.1.13-2.root.io.10"},{"fixed":"3.1.13-2.root.io.11"},{"fixed":"3.1.13-2.root.io.9"},{"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":"SUSE:Linux Enterprise Server 16.0","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.2.2-160000.3.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.2.2-160000.3.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.4.3-1.1"}]}],"bundled":3},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.2.2-160000.3.1"}]}]}],"products":[{"vendor":"academysoftwarefoundation","product":"openexr"},{"vendor":"openexr","product":"openexr"}],"references":[{"url":"https://github.com/AcademySoftwareFoundation/openexr/security/advisories/GHSA-3h9h-qfvw-98hq","tags":["x_refsource_CONFIRM","exploit","Exploit","Vendor Advisory","advisory","web","report"]},{"url":"https://github.com/user-attachments/files/23024726/archive0.zip","tags":["x_refsource_MISC","Broken Link","web","report"]},{"url":"https://github.com/user-attachments/files/23024736/archive1.zip","tags":["x_refsource_MISC","Broken Link","web","report"]},{"url":"https://github.com/user-attachments/files/23024740/archive2.zip","tags":["x_refsource_MISC","Broken Link","web","report"]},{"url":"https://github.com/user-attachments/files/23024744/archive3.zip","tags":["x_refsource_MISC","Broken Link","web","report"]},{"url":"https://github.com/user-attachments/files/23024746/archive4.zip","tags":["x_refsource_MISC","Broken Link","web","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-64181","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-3h9h-qfvw-98hq","tags":["advisory"]},{"url":"https://errata.tuxcare.com/els_os/tuxcare9.6esu/CLSA-2026-1775211239.html","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/64xxx/CVE-2025-64181.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2025-64181","tags":["advisory"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr","tags":["package"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2710","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2711","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2712","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2713","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2740","tags":["advisory"]},{"url":"https://pypi.org/project/openexr","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202521014-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1253233","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2025-64181","tags":["web"]},{"url":"https://ubuntu.com/security/CVE-2025-64181","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-64181","tags":["report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/commit/72aa3e78acfb99eacae8bfae8bf4e4831634db11","tags":["report"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2025-64182","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-64183","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2025-64181","title":"OpenEXR Makes Use of Uninitialized Memory","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.5 and 3.4.0 through 3.4.2, while fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory. The issue can result in undefined behavior and/or a potential crash/denial of service. Versions 3.3.6 and 3.4.3 fix the issue.","status":"published","published":"2025-11-10T21:23:04.248Z","modified":"2025-11-12T21:05:26.971Z","cvss":[{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P","level":"low","assessor":"cna"}],"cwes":["CWE-457"],"updated_at":"2026-11-02T14:32:46.750177Z"}],"euvd":[{"id":"EUVD-2025-50828","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.5 and 3.4.0 through 3.4.2, while fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory. The issue can result in undefined behavior and/or a potential crash/denial of service. Versions 3.3.6 and 3.4.3 fix the issue.","status":"published","published":"2025-11-10T21:23:04Z","modified":"2025-11-12T21:05:26Z","cvss":[{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P","level":"low"}],"updated_at":"2026-11-02T19:49:17.986196Z"}],"ghsa":[{"id":"GHSA-3h9h-qfvw-98hq","title":"OpenEXR Makes Use of Uninitialized Memory","description":"### Summary\nWhile fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory (CWE-457). The issue is reproducible with the current OSS-Fuzz harness and a single-file PoC.\n\n### Details\n\n**Environment:**\n- Tooling: `valgrind --tool=memcheck --track-origins=yes`\n- Target: `openexr_exrcheck_fuzzer`\n- OS: Ubuntu 20.04.6 LTS focal x86_64\n- openexr version and Git-commit hash: ` openexr 3.4.2 | commit fd657e8a41e157e5841c7cc2e2a5efe094b069a1 (grafted, HEAD -\u003e main, origin/main, origin/HEAD)`\n\nFunction: `generic_unpack`\n\nPossible root cause (based on observed symptoms):\nThe unpacker is branching on bytes in a scratch buffer that were never written because the decode step didn’t fully populate it.\n- The first use flagged is in `generic_unpack()`. That function reads from the decompressed/expanded pixel buffer to scatter data into the framebuffer. A “conditional jump depends on uninitialised value(s)” means it’s consulting bytes in that buffer before they were written.\n- Valgrind says the uninitialised value “was created by a heap allocation (malloc)”, not the stack: this matches a per-tile/per-scanline decode scratch buffer allocated in `exr_decoding_run()`.\n\n**Valgrind Trace (top frames):**\n```bash\n==454== Conditional jump or move depends on uninitialised value(s)\n==454==    at 0x4539BE: generic_unpack (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x44B85F: exr_decoding_run (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x38BC5F: Imf_4_0::(anonymous namespace)::TileProcess::run_decode(_priv_exr_context_t const*, int, Imf_4_0::FrameBuffer const*, std::__1::vector\u003cImf_4_0::Slice, std::__1::allocator\u003cImf_4_0::Slice\u003e \u003e const\u0026) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x388BE1: Imf_4_0::TiledInputFile::Data::readTiles(int, int, int, int, int, int) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x388619: Imf_4_0::TiledInputFile::readTiles(int, int, int, int, int, int) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x353755: Imf_4_0::InputFile::Data::bufferedReadPixels(int, int) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x352286: Imf_4_0::InputFile::readPixels(int) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x3190FA: Imf_4_0::(anonymous namespace)::readMultiPart(Imf_4_0::MultiPartInputFile\u0026, bool, bool) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x314C4D: Imf_4_0::checkOpenEXRFile(char const*, unsigned long, bool, bool, bool) (in /out/openexr_exrcheck_fuzzer)\n==454==  Uninitialised value was created by a heap allocation at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)\n```\n\n### PoC\nIn the attached archive, you will find:\n- The executable used for our tests.\n- The testcase used to trigger the bug.\n\nTo observe the bug, simply run the OSS-Fuzz helper script:\n```bash\ngit clone https://github.com/google/oss-fuzz.git\ncd oss-fuzz\n\npython3 infra/helper.py build_image openexr\npython3 infra/helper.py build_fuzzers --sanitizer=none openexr\npython3 infra/helper.py shell openexr\n\napt update \u0026\u0026 apt install -y valgrind\nulimit -n 65535\nvalgrind --tool=memcheck --track-origins=yes /out/openexr_exrcheck_fuzzer /path/to/poc\n```\n\n### Impact\n- Undefined Behavior\n- Potential crash\n- Denial of Service\n\n**Credit:** Aldo Ristori\n[archive0.zip](https://github.com/user-attachments/files/23024726/archive0.zip)\n\n\n\n### Update Note:\nOther saved testcases from the fuzzing campaign trigger the same underlying bug, but with a different manifestation. So there is one root cause (missing post-decode validation / zero-init before any unpack), with different call-sites. Below there are several archives, formatted like the previous one, that reproduce the other test cases.\n\n**Other observed sinks (distinct manifestations of the same bug):**\n\n**Deep pointers path:**\ngeneric_unpack_deep_pointers (deep scanline/tiled)\n[archive1.zip](https://github.com/user-attachments/files/23024736/archive1.zip)\n\n\n**Deep sample table path:**\nunpack_sample_table (deep scanline)\n[archive2.zip](https://github.com/user-attachments/files/23024740/archive2.zip)\n\n\n**Half conversion path:**\nhalf_to_float_buffer_f16c via unpack_half_to_float_3chan_planar\n[archive3.zip](https://github.com/user-attachments/files/23024744/archive3.zip)\n\n\n**Deep compositing:**\nCompositeDeepScanLine::readPixels → ThreadPool::addTask → LineCompositeTask::execute\n[archive4.zip](https://github.com/user-attachments/files/23024746/archive4.zip)","status":"published","published":"2026-04-06T17:51:11Z","modified":"2026-04-06T17:51:13Z","cvss":[{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P","level":"low"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-457"],"updated_at":"2026-11-02T14:39:48.966685Z"}],"nvd":[{"id":"CVE-2025-64181","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.5 and 3.4.0 through 3.4.2, while fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory. The issue can result in undefined behavior and/or a potential crash/denial of service. Versions 3.3.6 and 3.4.3 fix the issue.","status":"published","published":"2025-11-10T22:15:36.933Z","modified":"2026-06-17T09:53:58.16Z","cvss":[{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/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":"low","assessor":"secondary"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"primary"}],"cwes":["CWE-457"],"updated_at":"2026-11-02T14:11:42.870953Z"}],"osv":[{"id":"CVE-2025-64181","title":"OpenEXR Makes Use of Uninitialized Memory","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.5 and 3.4.0 through 3.4.2, while fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory. The issue can result in undefined behavior and/or a potential crash/denial of service. Versions 3.3.6 and 3.4.3 fix the issue.","status":"published","published":"2025-11-10T21:23:04.248Z","modified":"2026-10-28T02:30:26.244080243Z","cvss":[{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P","level":"low"}],"cwes":["CWE-457"],"updated_at":"2026-11-02T15:44:51.851511Z"},{"id":"DEBIAN-CVE-2025-64181","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.5 and 3.4.0 through 3.4.2, while fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory. The issue can result in undefined behavior and/or a potential crash/denial of service. Versions 3.3.6 and 3.4.3 fix the issue.","status":"published","published":"2025-11-10T22:15:36.933Z","modified":"2026-09-01T20:05:55.5760044Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T15:45:47.697959Z"},{"id":"GHSA-3h9h-qfvw-98hq","title":"OpenEXR Makes Use of Uninitialized Memory","description":"### Summary\nWhile fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory (CWE-457). The issue is reproducible with the current OSS-Fuzz harness and a single-file PoC.\n\n### Details\n\n**Environment:**\n- Tooling: `valgrind --tool=memcheck --track-origins=yes`\n- Target: `openexr_exrcheck_fuzzer`\n- OS: Ubuntu 20.04.6 LTS focal x86_64\n- openexr version and Git-commit hash: ` openexr 3.4.2 | commit fd657e8a41e157e5841c7cc2e2a5efe094b069a1 (grafted, HEAD -\u003e main, origin/main, origin/HEAD)`\n\nFunction: `generic_unpack`\n\nPossible root cause (based on observed symptoms):\nThe unpacker is branching on bytes in a scratch buffer that were never written because the decode step didn’t fully populate it.\n- The first use flagged is in `generic_unpack()`. That function reads from the decompressed/expanded pixel buffer to scatter data into the framebuffer. A “conditional jump depends on uninitialised value(s)” means it’s consulting bytes in that buffer before they were written.\n- Valgrind says the uninitialised value “was created by a heap allocation (malloc)”, not the stack: this matches a per-tile/per-scanline decode scratch buffer allocated in `exr_decoding_run()`.\n\n**Valgrind Trace (top frames):**\n```bash\n==454== Conditional jump or move depends on uninitialised value(s)\n==454==    at 0x4539BE: generic_unpack (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x44B85F: exr_decoding_run (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x38BC5F: Imf_4_0::(anonymous namespace)::TileProcess::run_decode(_priv_exr_context_t const*, int, Imf_4_0::FrameBuffer const*, std::__1::vector\u003cImf_4_0::Slice, std::__1::allocator\u003cImf_4_0::Slice\u003e \u003e const\u0026) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x388BE1: Imf_4_0::TiledInputFile::Data::readTiles(int, int, int, int, int, int) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x388619: Imf_4_0::TiledInputFile::readTiles(int, int, int, int, int, int) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x353755: Imf_4_0::InputFile::Data::bufferedReadPixels(int, int) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x352286: Imf_4_0::InputFile::readPixels(int) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x3190FA: Imf_4_0::(anonymous namespace)::readMultiPart(Imf_4_0::MultiPartInputFile\u0026, bool, bool) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x314C4D: Imf_4_0::checkOpenEXRFile(char const*, unsigned long, bool, bool, bool) (in /out/openexr_exrcheck_fuzzer)\n==454==  Uninitialised value was created by a heap allocation at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)\n```\n\n### PoC\nIn the attached archive, you will find:\n- The executable used for our tests.\n- The testcase used to trigger the bug.\n\nTo observe the bug, simply run the OSS-Fuzz helper script:\n```bash\ngit clone https://github.com/google/oss-fuzz.git\ncd oss-fuzz\n\npython3 infra/helper.py build_image openexr\npython3 infra/helper.py build_fuzzers --sanitizer=none openexr\npython3 infra/helper.py shell openexr\n\napt update \u0026\u0026 apt install -y valgrind\nulimit -n 65535\nvalgrind --tool=memcheck --track-origins=yes /out/openexr_exrcheck_fuzzer /path/to/poc\n```\n\n### Impact\n- Undefined Behavior\n- Potential crash\n- Denial of Service\n\n**Credit:** Aldo Ristori\n[archive0.zip](https://github.com/user-attachments/files/23024726/archive0.zip)\n\n\n\n### Update Note:\nOther saved testcases from the fuzzing campaign trigger the same underlying bug, but with a different manifestation. So there is one root cause (missing post-decode validation / zero-init before any unpack), with different call-sites. Below there are several archives, formatted like the previous one, that reproduce the other test cases.\n\n**Other observed sinks (distinct manifestations of the same bug):**\n\n**Deep pointers path:**\ngeneric_unpack_deep_pointers (deep scanline/tiled)\n[archive1.zip](https://github.com/user-attachments/files/23024736/archive1.zip)\n\n\n**Deep sample table path:**\nunpack_sample_table (deep scanline)\n[archive2.zip](https://github.com/user-attachments/files/23024740/archive2.zip)\n\n\n**Half conversion path:**\nhalf_to_float_buffer_f16c via unpack_half_to_float_3chan_planar\n[archive3.zip](https://github.com/user-attachments/files/23024744/archive3.zip)\n\n\n**Deep compositing:**\nCompositeDeepScanLine::readPixels → ThreadPool::addTask → LineCompositeTask::execute\n[archive4.zip](https://github.com/user-attachments/files/23024746/archive4.zip)","status":"published","published":"2026-04-06T17:51:11Z","modified":"2026-07-13T16:43:02.056352689Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"},{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P","level":"low"}],"cwes":["CWE-457"],"updated_at":"2026-11-02T15:46:35.747385Z"},{"id":"OESA-2025-2710","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. In versions 3.3.0 through 3.3.5 and 3.4.0 through 3.4.2, while fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory. The issue can result in undefined behavior and/or a potential crash/denial of service. Versions 3.3.6 and 3.4.3 fix the issue.(CVE-2025-64181)","status":"published","published":"2025-11-22T11:09:50Z","modified":"2026-08-18T01:19:20.101136905Z","cvss":[{"version":"3.1","score":4,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"updated_at":"2026-11-02T15:52:44.957082Z"},{"id":"OESA-2025-2711","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. In versions 3.3.0 through 3.3.5 and 3.4.0 through 3.4.2, while fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory. The issue can result in undefined behavior and/or a potential crash/denial of service. Versions 3.3.6 and 3.4.3 fix the issue.(CVE-2025-64181)","status":"published","published":"2025-11-22T11:09:50Z","modified":"2026-08-18T01:19:20.799324528Z","cvss":[{"version":"3.1","score":4,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"updated_at":"2026-11-02T15:52:44.957082Z"},{"id":"OESA-2025-2712","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. In versions 3.3.0 through 3.3.5 and 3.4.0 through 3.4.2, while fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory. The issue can result in undefined behavior and/or a potential crash/denial of service. Versions 3.3.6 and 3.4.3 fix the issue.(CVE-2025-64181)","status":"published","published":"2025-11-22T11:09:50Z","modified":"2026-08-18T01:19:20.85960469Z","cvss":[{"version":"3.1","score":4,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"updated_at":"2026-11-02T15:52:44.957082Z"},{"id":"OESA-2025-2713","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. In versions 3.3.0 through 3.3.5 and 3.4.0 through 3.4.2, while fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory. The issue can result in undefined behavior and/or a potential crash/denial of service. Versions 3.3.6 and 3.4.3 fix the issue.(CVE-2025-64181)","status":"published","published":"2025-11-22T11:09:50Z","modified":"2026-08-18T01:19:20.868071985Z","cvss":[{"version":"3.1","score":4,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"updated_at":"2026-11-02T15:52:44.957082Z"},{"id":"OESA-2025-2740","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. In versions 3.3.0 through 3.3.5 and 3.4.0 through 3.4.2, while fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory. The issue can result in undefined behavior and/or a potential crash/denial of service. Versions 3.3.6 and 3.4.3 fix the issue.(CVE-2025-64181)","status":"published","published":"2025-11-28T11:09:51Z","modified":"2026-08-18T01:19:20.204003001Z","cvss":[{"version":"3.1","score":4,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"updated_at":"2026-11-02T15:52:45.339366Z"},{"id":"PYSEC-2026-2843","title":"OpenEXR Makes Use of Uninitialized Memory","description":"### Summary\nWhile fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory (CWE-457). The issue is reproducible with the current OSS-Fuzz harness and a single-file PoC.\n\n### Details\n\n**Environment:**\n- Tooling: `valgrind --tool=memcheck --track-origins=yes`\n- Target: `openexr_exrcheck_fuzzer`\n- OS: Ubuntu 20.04.6 LTS focal x86_64\n- openexr version and Git-commit hash: ` openexr 3.4.2 | commit fd657e8a41e157e5841c7cc2e2a5efe094b069a1 (grafted, HEAD -\u003e main, origin/main, origin/HEAD)`\n\nFunction: `generic_unpack`\n\nPossible root cause (based on observed symptoms):\nThe unpacker is branching on bytes in a scratch buffer that were never written because the decode step didn’t fully populate it.\n- The first use flagged is in `generic_unpack()`. That function reads from the decompressed/expanded pixel buffer to scatter data into the framebuffer. A “conditional jump depends on uninitialised value(s)” means it’s consulting bytes in that buffer before they were written.\n- Valgrind says the uninitialised value “was created by a heap allocation (malloc)”, not the stack: this matches a per-tile/per-scanline decode scratch buffer allocated in `exr_decoding_run()`.\n\n**Valgrind Trace (top frames):**\n```bash\n==454== Conditional jump or move depends on uninitialised value(s)\n==454==    at 0x4539BE: generic_unpack (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x44B85F: exr_decoding_run (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x38BC5F: Imf_4_0::(anonymous namespace)::TileProcess::run_decode(_priv_exr_context_t const*, int, Imf_4_0::FrameBuffer const*, std::__1::vector\u003cImf_4_0::Slice, std::__1::allocator\u003cImf_4_0::Slice\u003e \u003e const\u0026) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x388BE1: Imf_4_0::TiledInputFile::Data::readTiles(int, int, int, int, int, int) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x388619: Imf_4_0::TiledInputFile::readTiles(int, int, int, int, int, int) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x353755: Imf_4_0::InputFile::Data::bufferedReadPixels(int, int) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x352286: Imf_4_0::InputFile::readPixels(int) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x3190FA: Imf_4_0::(anonymous namespace)::readMultiPart(Imf_4_0::MultiPartInputFile\u0026, bool, bool) (in /out/openexr_exrcheck_fuzzer)\n==454==    by 0x314C4D: Imf_4_0::checkOpenEXRFile(char const*, unsigned long, bool, bool, bool) (in /out/openexr_exrcheck_fuzzer)\n==454==  Uninitialised value was created by a heap allocation at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)\n```\n\n### PoC\nIn the attached archive, you will find:\n- The executable used for our tests.\n- The testcase used to trigger the bug.\n\nTo observe the bug, simply run the OSS-Fuzz helper script:\n```bash\ngit clone https://github.com/google/oss-fuzz.git\ncd oss-fuzz\n\npython3 infra/helper.py build_image openexr\npython3 infra/helper.py build_fuzzers --sanitizer=none openexr\npython3 infra/helper.py shell openexr\n\napt update \u0026\u0026 apt install -y valgrind\nulimit -n 65535\nvalgrind --tool=memcheck --track-origins=yes /out/openexr_exrcheck_fuzzer /path/to/poc\n```\n\n### Impact\n- Undefined Behavior\n- Potential crash\n- Denial of Service\n\n**Credit:** Aldo Ristori\n[archive0.zip](https://github.com/user-attachments/files/23024726/archive0.zip)\n\n\n\n### Update Note:\nOther saved testcases from the fuzzing campaign trigger the same underlying bug, but with a different manifestation. So there is one root cause (missing post-decode validation / zero-init before any unpack), with different call-sites. Below there are several archives, formatted like the previous one, that reproduce the other test cases.\n\n**Other observed sinks (distinct manifestations of the same bug):**\n\n**Deep pointers path:**\ngeneric_unpack_deep_pointers (deep scanline/tiled)\n[archive1.zip](https://github.com/user-attachments/files/23024736/archive1.zip)\n\n\n**Deep sample table path:**\nunpack_sample_table (deep scanline)\n[archive2.zip](https://github.com/user-attachments/files/23024740/archive2.zip)\n\n\n**Half conversion path:**\nhalf_to_float_buffer_f16c via unpack_half_to_float_3chan_planar\n[archive3.zip](https://github.com/user-attachments/files/23024744/archive3.zip)\n\n\n**Deep compositing:**\nCompositeDeepScanLine::readPixels → ThreadPool::addTask → LineCompositeTask::execute\n[archive4.zip](https://github.com/user-attachments/files/23024746/archive4.zip)","status":"published","published":"2026-07-13T14:36:48.278249Z","modified":"2026-07-13T16:32:32.950394461Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"},{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P","level":"low"}],"updated_at":"2026-11-02T15:52:56.429374Z"},{"id":"ROOT-OS-DEBIAN-12-CVE-2025-64181","title":"CVE-2025-64181 in openexr - Patched by Root","description":"Root has patched CVE-2025-64181 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:06.092771706Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T15:53:31.514195Z"},{"id":"ROOT-OS-DEBIAN-13-CVE-2025-64181","title":"CVE-2025-64181 in openexr - Patched by Root","description":"Root has patched CVE-2025-64181 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:03.394927446Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T15:53:33.153539Z"},{"id":"UBUNTU-CVE-2025-64181","description":"OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.5 and 3.4.0 through 3.4.2, while fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory. The issue can result in undefined behavior and/or a potential crash/denial of service. Versions 3.3.6 and 3.4.3 fix the issue.","status":"withdrawn","published":"2025-11-10T22:15:00Z","modified":"2026-04-27T18:53:56.505337Z","cvss":[{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P","level":"low"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T16:55:52.345622Z"},{"id":"CLSA-2026-1775211239","title":"openexr: Fix of 4 CVEs","description":"- CVE-2025-12495 CVE-2025-12839 CVE-2025-12840: fix heap buffer overflows\n  in the C core decoding pipeline (missing nread validation in\n  exr_read_chunk, missing packed/unpacked size check for uncompressed tiles,\n  missing storage_mode guard in chunk offset computation)\n- CVE-2025-64181: fix use of uninitialized memory caused by incompletely\n  populated scratch buffers (addressed by the same precondition guards in\n  chunk.c and parse_header.c)","status":"published","published":"2026-04-03T10:14:03Z","modified":"2026-06-01T00:32:46.374001224Z","updated_at":"2026-11-02T15:43:44.009773Z"},{"id":"openSUSE-SU-2025:15741-1","title":"libIex-3_4-33-3.4.3-1.1 on GA media","description":"These are all security issues fixed in the libIex-3_4-33-3.4.3-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2025-11-18T00:00:00Z","modified":"2026-03-23T04:54:09.181745Z","updated_at":"2026-11-02T16:58:37.810934Z"},{"id":"openSUSE-SU-2025:20056-1","title":"Security update for openexr","description":"This update for openexr fixes the following issues:\n\n- CVE-2025-64181: Fixed use of uninitialized memory in function generic_unpack() (bsc#1253233)\n","status":"published","published":"2025-11-19T09:45:59Z","modified":"2026-03-23T04:54:16.074661Z","updated_at":"2026-11-02T16:58:38.101535Z"},{"id":"SUSE-SU-2025:21014-1","title":"Security update for openexr","description":"This update for openexr fixes the following issues:\n\n- CVE-2025-64181: Fixed use of uninitialized memory in function generic_unpack() (bsc#1253233)\n","status":"published","published":"2025-11-19T09:46:11Z","modified":"2026-03-23T04:50:18.65193Z","updated_at":"2026-11-02T15:53:59.92114Z"}]}}