Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍 PyPI
Not in CISA KEV

GHSA-x22w-82jp-8rvf — openexr

Fix: AcademySoftwareFoundation/openexr@2df7802

GHSA-x22w-82jp-8rvf is a CWE-770 vulnerability in openexr. A fix is available for openexr — see the affected versions and patch details below.

OpenEXR Out-Of-Memory via Unbounded File Header Values

Also known asCVE-2025-48074PYSEC-2026-1749
Published
Jul 31, 2025
Updated
Jul 7, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 20, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-x22w-82jp-8rvf.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs18th percentile — riskier than 18% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Real-World Exposure

1 pkg affected
🐍openexr

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

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.

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
  1. 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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIopenexr≥ 3.3.2&&< 3.3.33.3.3pip install --upgrade 'openexr==3.3.3'

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for openexr, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update openexr to 3.3.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x22w-82jp-8rvf is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-x22w-82jp-8rvf can be triaged on real exposure rather than presence alone.

Tailored to GHSA-x22w-82jp-8rvf. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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
O3 Security · Impact-Aware SCA

Is GHSA-x22w-82jp-8rvf in your dependencies?

O3 Security finds GHSA-x22w-82jp-8rvf across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

Scan my dependencies How O3 SCA works
GHSA-x22w-82jp-8rvf: openexr DoS | O3 Security