← Back to results
Vulnerability record · public intelligence
CVE-2026-68514
MEDIUM

OpenEXR: Heap buffer overflow in PyOpenEXR from literal/prefixed RGB channel name collision in deep images

Published Aug 25, 2026 · Updated Nov 3, 2026

Severity · CVSSMEDIUM · Not scored
Known exploitationNot listed
EPSS / likelihood0.18%
QFinch risk scoreNot available

Original summary

Normalized public record · Updated Nov 3, 2026

OpenEXR: Heap buffer overflow in PyOpenEXR from literal/prefixed RGB channel name collision in deep images

Publisher and source text is retained separately from QFinch interpretation.

QFinch assessment

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 contain a heap out-of-bounds write triggered when reading a crafted deep scanline EXR file. When a deep file declares a literal channel named left alongside layer-prefixed RGB channels left.R, left.G, and left.B, the wrapper processes the literal left channel first and allocates a scalar deep sample array for it, then reuses that same array as the coalesced destination for the prefixed RGB group. The deep reader registers sample slices with an RGB stride (three lanes) into storage that was allocated with scalar shape, so decoding the deep samples writes past the allocation. Opening such a file through the default public Python API, OpenEXR.File(path), causes a heap buffer overflow during normal deep sample decode, leading to memory corruption and a crash. This issue is fixed in versions 3.3.13 and 3.4.14.

Evidence: public source records

Affected products

Affected scope reported by the available public evidence
Affected package, product or rangeFix status
Consult the referenced vendor advisory for affected versions.Consult source advisory

Matching a version is only one part of assessing exposure. QFinch has not assessed your environment on this public page.

Remediation

Apply the vendor-supported fixed release or mitigation, then verify the affected component is no longer reachable.

  1. Confirm the affected product and reachable code path exist in your environment.
  2. Apply the vendor-supported patch or mitigation from the primary advisory.
  3. Rescan the exact deployed revision and retain verification evidence.
Review primary references

Evidence coverage

FIRST-EPSSCVE-LIST-V5
SSVC priority
LOW
Confidence
Not available
Aliases
None reported

Scores appear only when corresponding evidence exists. Missing data is never interpreted as zero risk.

Sources and record history

  1. Security advisory ↗
  2. Patch commit ↗
  3. Patch commit ↗

Record history

Published Aug 25, 2026 · Last refreshed Nov 3, 2026