CVE-2026-62986: OpenEXR: PyOpenEXR deep prefixed RGB stale lane disclosure

Published Aug 25, 2026
·
Updated

OpenEXR is the reference implementation and specification for the EXR image file format, widely used in the motion picture industry. In versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13, the PyOpenEXR Python bindings return stale heap data when reading a crafted deep scanline EXR that uses layer-prefixed RGB channels. With the default channel coalescing (separatechannels=False), the wrapper groups channels such as left.R, left.G, and left.B into a single RGB sample array, but the lane-offset calculation in PyPart::setDeepSliceData() only recognizes the exact unprefixed names G, B, and A. As a result, prefixed channels like left.G and left.B are decoded into lane 0 while lanes 1 and 2 are left uninitialized and returned to Python. A Python application that reads untrusted deep EXR files through the default OpenEXR.File API and then logs, serializes, previews, or otherwise processes the resulting NumPy sample arrays may expose uninitialized same-process heap contents, in addition to receiving incorrect green and blue channel data. This issue is fixed in versions 3.3.13 and 3.4.14.

Affected Software

2 affected components
OpenEXR PyOpenEXR>=3.3.0<=3.3.12, >=3.4.0<=3.4.13
OpenEXR PyOpenEXR<3.3.13, <3.4.14

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade PyOpenEXR to a version that resolves this vulnerability.

    Fixed in 3.3.13
  2. Upgrade

    Upgrade PyOpenEXR to a version that resolves this vulnerability.

    Fixed in 3.4.14

Event History

Aug 25, 2026
CVE Published
via MITRE·06:27 PM
Data Sourced
via MITRE·06:27 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·07:16 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are affected?

PyOpenEXR bindings in OpenEXR versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13 are affected. The issue applies when reading deep scanline EXR files with layer-prefixed RGB channels through the Python bindings.

2

What must an attacker provide to trigger the disclosure?

An attacker needs to cause a Python application to read a crafted deep scanline EXR containing prefixed channels such as left.R, left.G, and left.B. No authentication or special privileges are required, but user interaction is required to have the application process the file.

3

Are applications using the default Python file-reading behavior exposed?

Yes. The affected behavior occurs with the default channel coalescing setting, separate_channels=False, used by the OpenEXR.File API. Applications that log, serialize, preview, or otherwise expose the returned NumPy sample arrays may disclose uninitialized heap contents.

4

What version should be used to remediate the issue?

Upgrade to OpenEXR 3.3.13 or later in the 3.3 series, or 3.4.14 or later in the 3.4 series.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203