{"id":"CVE-2026-45696","aliases":["ALPINE-CVE-2026-45696","BELL-CVE-2026-45696","DEBIAN-CVE-2026-45696","EUVD-2026-37948","GHSA-gjpj-qv64-vwhf","JLSEC-2026-813","UBUNTU-CVE-2026-45696","openSUSE-SU-2026:10985-1"],"status":"published","title":"OpenEXR HTJ2K decoder heap buffer over-read in ht_undo_impl() (DoS)","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, the HTJ2K (High-Throughput JPEG 2000) decoder, ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The  ht_undo_imp function copies decoded pixels out of a per-line OpenJPH buffer using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can declare different (smaller) tile/line dimensions than the EXR header advertises, but ht_undo_impl() does not validate this — it pulls width 32-bit samples from cur_line-\u003ei32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.","severity":{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00418,"percentile":0.36526,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-122","CWE-125"],"published":"2026-06-09T00:00:00Z","modified":"2026-11-03T06:33:03Z","fixes":[{"ecosystem":"Alpine:v3.23","package":"openexr","fixed_in":["3.4.13-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.24","package":"openexr","fixed_in":["3.4.13-r0"],"sources":["osv"]},{"ecosystem":"Alpaquita:stream","package":"openexr","fixed_in":["3.4.13-r0"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"openexr","fixed_in":["3.4.14-0.1"],"sources":["osv"]},{"ecosystem":"Julia","package":"OpenEXR_jll","fixed_in":["3.4.12+0"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Alpine:v3.23","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.4.0"},{"fixed":"3.4.13-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.24","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.4.0"},{"fixed":"3.4.13-r0"}]}]},{"source":"osv","ecosystem":"Alpaquita:stream","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.4.4-r0"},{"fixed":"3.4.13-r0"}]}]},{"source":"osv","ecosystem":"Debian:14","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.4.14-0.1"}]}],"versions":["3.1.13-2","3.4.6+ds-1","3.4.6+ds-2","3.4.6+ds-3","3.4.6+ds-4"]},{"source":"osv","ecosystem":"Julia","package":"OpenEXR_jll","ranges":[{"type":"SEMVER","events":[{"introduced":"3.4.4+0"},{"fixed":"3.4.12+0"}]}]},{"source":"osv","ecosystem":"Ubuntu:Pro:16.04:LTS","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.2.0-1ubuntu3","2.2.0-7ubuntu1","2.2.0-9ubuntu1","2.2.0-10ubuntu2","2.2.0-10ubuntu2.1","2.2.0-10ubuntu2.2","2.2.0-10ubuntu2.3","2.2.0-10ubuntu2.4","2.2.0-10ubuntu2.6","2.2.0-10ubuntu2.6+esm1","2.2.0-10ubuntu2.6+esm2","2.2.0-10ubuntu2.6+esm3","2.2.0-10ubuntu2.6+esm4"]},{"source":"osv","ecosystem":"Ubuntu:Pro:18.04:LTS","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.2.0-11ubuntu1","2.2.0-11.1ubuntu1","2.2.0-11.1ubuntu1.1","2.2.0-11.1ubuntu1.2","2.2.0-11.1ubuntu1.3","2.2.0-11.1ubuntu1.4","2.2.0-11.1ubuntu1.6","2.2.0-11.1ubuntu1.7","2.2.0-11.1ubuntu1.8","2.2.0-11.1ubuntu1.9","2.2.0-11.1ubuntu1.9+esm1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:20.04:LTS","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.2.1-4.1ubuntu1","2.3.0-6","2.3.0-6build1","2.3.0-6ubuntu0.1","2.3.0-6ubuntu0.2","2.3.0-6ubuntu0.3","2.3.0-6ubuntu0.5","2.3.0-6ubuntu0.5+esm1","2.3.0-6ubuntu0.5+esm2"]},{"source":"osv","ecosystem":"Ubuntu:Pro:22.04:LTS","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.5.4-2","2.5.7-1","2.5.7-1ubuntu0.1~esm1","2.5.7-1ubuntu0.1~esm2"]},{"source":"osv","ecosystem":"Ubuntu:Pro:24.04:LTS","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.5-5.1","3.1.5-5.1build1","3.1.5-5.1build2","3.1.5-5.1build3","3.1.5-5.1ubuntu0.1~esm1"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.13-2"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.13-2build1","3.4.6+ds-4ubuntu3"]},{"source":"osv","ecosystem":"Ubuntu:Pro:26.04:LTS","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.13-2","3.1.13-2build1","3.1.13-2ubuntu0.26.04.1~esm1"]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.4.12-1.1"}]}],"bundled":2}],"products":[{"vendor":"academysoftwarefoundation","product":"openexr"},{"vendor":"openexr","product":"openexr"},{"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-gjpj-qv64-vwhf","tags":["x_refsource_CONFIRM","exploit","Exploit","Vendor Advisory","advisory","web","report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.4.12","tags":["x_refsource_MISC","Release Notes","web","report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-45696","tags":["vdb-entry","x_refsource_REDHAT","advisory","web"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2490597","tags":["issue-tracking","x_refsource_REDHAT","report","web"]},{"url":"https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-45696.json","tags":["x_sadp-csaf-vex","web"]},{"url":"https://security.alpinelinux.org/vuln/CVE-2026-45696","tags":["advisory"]},{"url":"https://docs.bell-sw.com/security/cves/CVE-2026-45696","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45696.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45696","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-45696","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2026-45696","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-45696","tags":["report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/pull/2397","tags":["report"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44663","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-45696","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2026-45696","title":"OpenEXR HTJ2K decoder heap buffer over-read in ht_undo_impl() (DoS)","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, the HTJ2K (High-Throughput JPEG 2000) decoder, ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The  ht_undo_imp function copies decoded pixels out of a per-line OpenJPH buffer using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can declare different (smaller) tile/line dimensions than the EXR header advertises, but ht_undo_impl() does not validate this — it pulls width 32-bit samples from cur_line-\u003ei32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.","status":"published","published":"2026-06-18T20:31:56.603Z","modified":"2026-07-15T00:52:21.623Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA: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:L/I:N/A:H","level":"high","assessor":"adp"}],"cwes":["CWE-122","CWE-125"],"updated_at":"2026-11-02T13:46:32.755125Z"}],"euvd":[{"id":"EUVD-2026-37948","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, the HTJ2K (High-Throughput JPEG 2000) decoder, ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The  ht_undo_imp function copies decoded pixels out of a per-line OpenJPH buffer using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can declare different (smaller) tile/line dimensions than the EXR header advertises, but ht_undo_impl() does not validate this — it pulls width 32-bit samples from cur_line-\u003ei32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.","status":"published","published":"2026-06-18T20:31:56Z","modified":"2026-07-15T00:52:21Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H","level":"high"}],"updated_at":"2026-11-02T18:19:56.918546Z"}],"nvd":[{"id":"CVE-2026-45696","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, the HTJ2K (High-Throughput JPEG 2000) decoder, ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The  ht_undo_imp function copies decoded pixels out of a per-line OpenJPH buffer using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can declare different (smaller) tile/line dimensions than the EXR header advertises, but ht_undo_impl() does not validate this — it pulls width 32-bit samples from cur_line-\u003ei32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.","status":"published","published":"2026-06-18T21:16:28.917Z","modified":"2026-10-25T23:10:00.167Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/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":"high","assessor":"secondary"},{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"primary"},{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-122","CWE-125"],"updated_at":"2026-11-02T14:12:24.912854Z"}],"osv":[{"id":"ALPINE-CVE-2026-45696","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, the HTJ2K (High-Throughput JPEG 2000) decoder, ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The  ht_undo_imp function copies decoded pixels out of a per-line OpenJPH buffer using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can declare different (smaller) tile/line dimensions than the EXR header advertises, but ht_undo_impl() does not validate this — it pulls width 32-bit samples from cur_line-\u003ei32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.","status":"published","published":"2026-06-18T21:16:28.917Z","modified":"2026-11-03T06:33:03.171272945Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-03T07:15:53.944853Z"},{"id":"BELL-CVE-2026-45696","status":"published","published":"2026-06-20T06:11:21.443529Z","modified":"2026-07-24T07:15:06.430425908Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:28:24.12174Z"},{"id":"CVE-2026-45696","title":"OpenEXR HTJ2K decoder heap buffer over-read in ht_undo_impl() (DoS)","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, the HTJ2K (High-Throughput JPEG 2000) decoder, ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The  ht_undo_imp function copies decoded pixels out of a per-line OpenJPH buffer using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can declare different (smaller) tile/line dimensions than the EXR header advertises, but ht_undo_impl() does not validate this — it pulls width 32-bit samples from cur_line-\u003ei32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.","status":"published","published":"2026-06-18T20:31:56.603Z","modified":"2026-10-28T02:31:11.022974761Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H","level":"high"}],"cwes":["CWE-122"],"updated_at":"2026-11-02T15:45:05.525666Z"},{"id":"DEBIAN-CVE-2026-45696","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, the HTJ2K (High-Throughput JPEG 2000) decoder, ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The  ht_undo_imp function copies decoded pixels out of a per-line OpenJPH buffer using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can declare different (smaller) tile/line dimensions than the EXR header advertises, but ht_undo_impl() does not validate this — it pulls width 32-bit samples from cur_line-\u003ei32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.","status":"published","published":"2026-06-18T21:16:28.917Z","modified":"2026-10-26T11:47:28.707416058Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:45:55.669088Z"},{"id":"JLSEC-2026-813","title":"Crafted HTJ2K compressed EXR files can trigger out of bounds reads in OpenEXR","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, the HTJ2K (High-Throughput JPEG 2000) decoder, `ht_undo_impl()` in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The  `ht_undo_imp` function copies decoded pixels out of a per-line OpenJPH buffer using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can declare different (smaller) tile/line dimensions than the EXR header advertises, but `ht_undo_impl()` does not validate this — it pulls width 32-bit samples from `cur_line-`\u003ei32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by `ojph::local::codestream::finalize_alloc()`. The bug is reachable through the standard scanline-decode entry point used by every consumer of `exr_decoding_run/Imf::checkOpenEXRFile`, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.","status":"published","published":"2026-07-29T14:18:08.707Z","modified":"2026-07-29T14:30:03.948928499Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"},{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/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":"high"}],"updated_at":"2026-11-02T15:47:19.003546Z"},{"id":"UBUNTU-CVE-2026-45696","description":"OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, the HTJ2K (High-Throughput JPEG 2000) decoder, ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The  ht_undo_imp function copies decoded pixels out of a per-line OpenJPH buffer using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can declare different (smaller) tile/line dimensions than the EXR header advertises, but ht_undo_impl() does not validate this — it pulls width 32-bit samples from cur_line-\u003ei32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.","status":"published","published":"2026-06-18T21:16:00Z","modified":"2026-10-17T12:58:22.885289103Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H","level":"high"},{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H","level":"high"},{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T16:56:26.396868Z"},{"id":"openSUSE-SU-2026:10985-1","title":"libIex-3_4-33-3.4.12-1.1 on GA media","description":"These are all security issues fixed in the libIex-3_4-33-3.4.12-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-06-09T00:00:00Z","modified":"2026-06-10T18:24:13.932644962Z","updated_at":"2026-11-02T16:58:38.95195Z"}]}}