CVE-2025-48072 is a critical heap-based buffer overflow (CVSS 9.1) in OpenEXR 3.3.2, the reference library for the EXR image format. Decompressing a DWAA-packed scan-line file with a forged chunk triggers it, caused by bad pointer math. Upgrade to OpenEXR 3.3.3 and rebuild anything that bundles the library.
What's affected
Per the CVE record and the GitHub advisory, OpenEXR version 3.3.2 is affected, and version 3.3.3 contains the fix.
The advisory places the bug in the OpenEXRCore decoder for DWAA compression, in a code path that is used when SSE2 is enabled. A pointer into the data is advanced by the wrong amount, so a read runs past the end of a buffer on the heap. A maliciously forged chunk in an EXR file is what triggers it.
The record files this under CWE-125 (Out-of-bounds Read), which is an out-of-bounds read. The base vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H, which is network reachable with no privileges and no interaction, and high confidentiality and availability impact. The attack happens through a file, so the real route in is anything that decodes EXR files from outside, such as an upload feature, a render farm or an image pipeline.
OpenEXR is a library, so the question for most teams is which of their applications include it, directly or through another package.
How to check if you're exposed
On a Linux host, check the installed library version:
pkg-config --modversion OpenEXR
dpkg -l | grep -i openexr
rpm -qa | grep -i openexr
Only one of the last two will apply, depending on your distribution. A reading of 3.3.2 is affected, and 3.3.3 or later contains the fix.
For source projects, look at your dependency files and lock files for OpenEXR and for packages that wrap or vendor it. Image tools, 3D software, compositing tools and some Python imaging stacks include it, sometimes as a bundled copy inside a wheel or an application folder.
For containers, scan the image contents, not just the base image. A bundled copy will not show up in a system package query. You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your projects pull in the affected component.
What to do now
- Upgrade OpenEXR to 3.3.3 or later in every place you build or install it.
- Rebuild and redeploy applications and containers that vendor or statically link the library, since updating the system package does not change a bundled copy.
- Find places where untrusted EXR files are decoded automatically, such as thumbnailing, upload preview or asset import, and note them.
- Until you can update, avoid decoding EXR files from sources you do not trust, or run the decoder in a sandboxed or low privilege process.
- Check the OpenEXR 3.3.3 release notes for any other changes that affect your build options.
- Re-scan your projects after the upgrade to confirm no copy of 3.3.2 remains.
Why it matters
A heap buffer is a block of memory the program asks for while it runs. Reading past the end of it means the program reads whatever sits next to it, which can expose other data or crash the process. In an image decoder, the length values come from the file itself, so a forged file can lie about sizes. The fix in cases like this is to check every computed offset against the real buffer size.
The advisory describes the cause as bad pointer math, in which a pointer to 128 bit values was advanced as though it pointed to smaller units. It is a small mistake with large consequences, and it is the kind of bug that code review rarely spots.
It is not listed in the CISA Known Exploited Vulnerabilities catalog, and the record does not report exploitation in the wild. The practical risk depends on reachability. A library can be vulnerable in a build where nothing ever feeds it untrusted files, and that is exactly the question a reachability analysis answers: does your code actually call the decoder on outside input?
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect me if I only create EXR files?
The flaw is in decoding DWAA-packed scan-line files, so the risk is in reading files. If your software only writes them, the vulnerable path is not used, but upgrade anyway when you next rebuild.
How do I find bundled copies?
Look inside application folders, Python wheels and container layers for OpenEXR libraries, and scan the SBOM or the image rather than the system package list alone.
Sources
- NVD record for CVE-2025-48072
- OpenEXR GitHub security advisory GHSA-4r7w-q3jg-ff43
- OpenEXR v3.3.3 release (listed in the record)
Last reviewed: 18 October 2026.
