CVE-2026-55059: OpenEXR: OpenEXRUtil SampleCountChannel row setter heap has an out-of-bounds write vulnerability
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. Versions prior to 3.2.10, 3.3.12 and 3.4.13 contain a heap out-of-bounds write in Imf40::SampleCountChannel::set(int r, unsigned int newNumSamples[]). The row-based sample-count setter computes the target Y coordinate with dataWindow.min.x instead of dataWindow.min.y. For a valid deep image data window where min.x != min.y, a valid row index can be translated into an invalid Y coordinate, causing writes before the allocated numSamples buffer. The vulnerability is reachable through the public OpenEXRUtil DeepImage API and can lead to heap corruption and process crashes. This issue has been fixed in versions 3.2.10, 3.3.12 and 3.4.13.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
OpenEXRUtil (OpenEXR)to a version that resolves this vulnerability.Fixed in 3.2.10 - Upgrade
Upgrade
OpenEXRUtil (OpenEXR)to a version that resolves this vulnerability.Fixed in 3.3.12 - Upgrade
Upgrade
OpenEXRUtil (OpenEXR)to a version that resolves this vulnerability.Fixed in 3.4.13 - Compensating control
If upgrading cannot be done immediately, mitigate by limiting exposure to the public OpenEXRUtil DeepImage API path that reaches Imf_4_0::SampleCountChannel::set(int r, unsigned int newNumSamples[]) to trusted inputs/operations only.
Event History
Frequently Asked Questions
Which applications are exposed to this flaw?
Applications using the public OpenEXRUtil DeepImage API and calling Imf_4_0::SampleCountChannel::set(int r, unsigned int newNumSamples[]) are exposed when they process a valid deep image data window with different min.x and min.y values.
What is required to trigger the out-of-bounds write?
The vulnerable row-based setter must be called with a valid row index for a deep image whose data window has min.x != min.y. The incorrect coordinate calculation can then translate that valid row into an invalid Y coordinate and write before the allocated _numSamples buffer.
What impact should defenders expect?
Successful triggering causes heap corruption and can crash the affected process. The supplied severity vector indicates local attack-vector conditions and user interaction, with integrity and availability impact.
Which versions contain the fix?
The issue is fixed in OpenEXR versions 3.2.10, 3.3.12, and 3.4.13. Versions prior to those releases in their respective version lines are affected.