### Summary The OpenEXR file format defines many information about the final image inside of the file header, such as the size of data/display window. The application trusts the value of `dataWindow` size provided in the header of the input file, and performs computations based on this value. This may result in unintended behaviors, such as excessively large number of iterations and/or huge memory allocations. ### Details A concrete example of this issue is present in the function `readScanline()` in `ImfCheckFile.cpp` at line 235, that performs a for-loop using the `dataWindow min.y` and `max.y` coordinates that can be arbitrarily large. ```cpp in.setFrameBuffer (i); int step = 1; // // try reading scanlines. Continue reading scanlines // even if an exception is encountered // for (int y = dw.min.y; y <= dw.max.y; y += step) // <-- THIS LOOP IS EXCESSIVE BECAUSE OF DW.MAX { try { in.readPixels (y); } catch (...) { threw = true; // // in reduceTime mode, fail immediately - the file is corrupt // if (reduceTime) { return threw; } } } ``` Another example occurs in the `EnvmapImage::resize` function that in turn calls `Array2D<T>::resizeEraseUnsafe` passing the `dataWindow` X and Y coordinates and perform a huge allocation. On some system, the allocator will simply return `std::bad_alloc` and crash. On other systems such as macOS, the allocator will happily continue with a "small" pre-allocation and allocate further memory whenever it is accessed. This is the case with the `EnvmapImage::clear` function that is called right after and fills the image RGB values with zeros, allocating tens of Gigabytes. ### PoC NOTE: please download the `oom_crash.exr` file via the following link: https://github.com/ShielderSec/poc/tree/main/CVE-2025-48074 1. Compile the `exrcheck` binary in a macOS or GNU/Linux machine with ASAN. 2. Open the `oom_crash.exr` file with the following command: ``` exrcheck oom_crash.exr ``` 3. Notice that `exrenvmap`/`exrcheck` crashes with ASAN stack-trace. ### Impact An attacker could cause a denial of service by stalling the application or exhaust memory by stalling the application in a loop which contains a memory leakage.
### Summary The OpenEXR file format defines many information about the final image inside of the file header, such as the size of data/display window. The application trusts the value of `dataWindow` size provided in the header of the input file, and performs computations based on this value. This may result in unintended behaviors, such as excessively large number of iterations and/or huge memory allocations. ### Details A concrete example of this issue is present in the function `readScanline()` in `ImfCheckFile.cpp` at line 235, that performs a for-loop using the `dataWindow min.y` and `max.y` coordinates that can be arbitrarily large. ```cpp in.setFrameBuffer (i); int step = 1; // // try reading scanlines. Continue reading scanlines // even if an exception is encountered // for (int y = dw.min.y; y <= dw.max.y; y += step) // <-- THIS LOOP IS EXCESSIVE BECAUSE OF DW.MAX { try { in.readPixels (y); } catch (...) { threw = true; // // in reduceTime mode, fail immediately - the file is corrupt // if (reduceTime) { return threw; } } } ``` Another example occurs in the `EnvmapImage::resize` function that in turn calls `Array2D<T>::resizeEraseUnsafe` passing the `dataWindow` X and Y coordinates and perform a huge allocation. On some system, the allocator will simply return `std::bad_alloc` and crash. On other systems such as macOS, the allocator will happily continue with a "small" pre-allocation and allocate further memory whenever it is accessed. This is the case with the `EnvmapImage::clear` function that is called right after and fills the image RGB values with zeros, allocating tens of Gigabytes. ### PoC NOTE: please download the `oom_crash.exr` file via the following link: https://github.com/ShielderSec/poc/tree/main/CVE-2025-48074 1. Compile the `exrcheck` binary in a macOS or GNU/Linux machine with ASAN. 2. Open the `oom_crash.exr` file with the following command: ``` exrcheck oom_crash.exr ``` 3. Notice that `exrenvmap`/`exrcheck` crashes with ASAN stack-trace. ### Impact An attacker could cause a denial of service by stalling the application or exhaust memory by stalling the application in a loop which contains a memory leakage.
Update OpenEXR to 3.3.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanOpenEXR Out-Of-Memory via Unbounded File Header Values affects OpenEXR (pip). Severity is medium. ### Summary The OpenEXR file format defines many information about the final image inside of the file header, such as the size of data/display window. The application trusts the value of `dataWindow` size provided in the header of the input file, and performs computations based on this value. This may result in unintended behaviors, such as excessively large number of iterations and/or huge memory allocations. ### Details A concrete example of this issue is present in the function `readScanline()` in `ImfCheckFile.cpp` at line 235, that performs a for-loop using the `dataWindow min.y` and `max.y` coordinates that can be arbitrarily large. ```cpp in.setFrameBuffer (i); int step = 1; // // try reading scanlines. Continue reading scanlines // even if an exception is encountered // for (int y = dw.min.y; y <= dw.max.y; y += step) // <-- THIS LOOP IS EXCESSIVE BECAUSE OF DW.MAX { try { in.readPixels (y); } catch (...) { threw = true; // // in reduceTime mode, fail immediately - the file is corrupt // if (reduceTime) { return threw; } } } ``` Another example occurs in the `EnvmapImage::resize` function that in turn calls `Array2D<T>::resizeEraseUnsafe` passing the `dataWindow` X and Y coordinates and perform a huge allocation. On some system, the allocator will simply return `std::bad_alloc` and crash. On other systems such as macOS, the allocator will happily continue with a "small" pre-allocation and allocate further memory whenever it is accessed. This is the case with the `EnvmapImage::clear` function that is called right after and fills the image RGB values with zeros, allocating tens of Gigabytes. ### PoC NOTE: please download the `oom_crash.exr` file via the following link: https://github.com/ShielderSec/poc/tree/main/CVE-2025-48074 1. Compile the `exrcheck` binary in a macOS or GNU/Linux machine with ASAN. 2. Open the `oom_crash.exr` file with the following command: ``` exrcheck oom_crash.exr ``` 3. Notice that `exrenvmap`/`exrcheck` crashes with ASAN stack-trace. ### Impact An attacker could cause a denial of service by stalling the application or exhaust memory by stalling the application in a loop which contains a memory leakage.
AI coding agents often install or upgrade packages automatically in pip. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| OpenEXRpip | =3.3.2 | 3.3.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate OpenEXR to 3.3.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanOpenEXR Out-Of-Memory via Unbounded File Header Values affects OpenEXR (pip). Severity is medium. ### Summary The OpenEXR file format defines many information about the final image inside of the file header, such as the size of data/display window. The application trusts the value of `dataWindow` size provided in the header of the input file, and performs computations based on this value. This may result in unintended behaviors, such as excessively large number of iterations and/or huge memory allocations. ### Details A concrete example of this issue is present in the function `readScanline()` in `ImfCheckFile.cpp` at line 235, that performs a for-loop using the `dataWindow min.y` and `max.y` coordinates that can be arbitrarily large. ```cpp in.setFrameBuffer (i); int step = 1; // // try reading scanlines. Continue reading scanlines // even if an exception is encountered // for (int y = dw.min.y; y <= dw.max.y; y += step) // <-- THIS LOOP IS EXCESSIVE BECAUSE OF DW.MAX { try { in.readPixels (y); } catch (...) { threw = true; // // in reduceTime mode, fail immediately - the file is corrupt // if (reduceTime) { return threw; } } } ``` Another example occurs in the `EnvmapImage::resize` function that in turn calls `Array2D<T>::resizeEraseUnsafe` passing the `dataWindow` X and Y coordinates and perform a huge allocation. On some system, the allocator will simply return `std::bad_alloc` and crash. On other systems such as macOS, the allocator will happily continue with a "small" pre-allocation and allocate further memory whenever it is accessed. This is the case with the `EnvmapImage::clear` function that is called right after and fills the image RGB values with zeros, allocating tens of Gigabytes. ### PoC NOTE: please download the `oom_crash.exr` file via the following link: https://github.com/ShielderSec/poc/tree/main/CVE-2025-48074 1. Compile the `exrcheck` binary in a macOS or GNU/Linux machine with ASAN. 2. Open the `oom_crash.exr` file with the following command: ``` exrcheck oom_crash.exr ``` 3. Notice that `exrenvmap`/`exrcheck` crashes with ASAN stack-trace. ### Impact An attacker could cause a denial of service by stalling the application or exhaust memory by stalling the application in a loop which contains a memory leakage.
AI coding agents often install or upgrade packages automatically in pip. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| OpenEXRpip | =3.3.2 | 3.3.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard