OpenEXR CVE-2026-55373

Exploitation requires that the target application uses the OpenEXRUtil public API - specifically SampleCountChannel::set(x, y, count) or SampleCountChannel::Edit - on EXR content supplied or influenced by an attacker. The CVSS PR:N designation means no authentication to the application is required, but the attacker must control the EXR file content presented to the library. Applications that exclusively process internally generated or cryptographically authenticated EXR files are not exploitable. The vulnerability is limited to deep-image EXR content that exercises the sample-count code path; standard scanline or tiled EXR images without deep channels may not reach the vulnerable function. Platform or privilege level does not limit exploitation beyond what the calling application enforces.

The CVSS 3.1 vector CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H yields a base score of 6.2, reflecting a purely availability-impacting flaw with no confidentiality or integrity consequences. The AV:L designation requires careful interpretation: the vector is 'local' in the sense that exploitation requires the application process to invoke the vulnerable API, but if an application reads EXR files from network sources - typical in VFX render farms and asset management systems - a remotely-supplied crafted file achieves the same outcome. EPSS data is not provided; given the library's niche deployment domain and absence from CISA KEV, opportunistic mass exploitation is unlikely, but targeted attacks against film-production or media-processing pipelines processing untrusted EXR content are credible. No POC has been publicly identified. The 'Information Disclosure' tag from the SUSE advisory conflicts with the CVSS C:N metric - this likely reflects a tagging artifact rather than a confirmed data-exposure component, and should not be treated as a confirmed confidentiality impact without further vendor clarification. Overall real-world priority is moderate: mission-critical in VFX/rendering workflows, lower in environments that do not process externally supplied EXR files.

An attacker who can deliver a crafted EXR file to a rendering pipeline or asset-management application built on OpenEXR crafts an image whose deep-image sample-count channel contains a pixel with a sample count of UINT_MAX. When the application calls SampleCountChannel::set or triggers endEdit() via the Edit destructor, the library enters the infinite loop inside roundListSizeUp(), hanging the worker process indefinitely. In a render farm context, this could block render slots or crash a deadline-sensitive production pipeline with a single malicious file submission. No public exploit code exists, but the vulnerability mechanics are straightforward and derivable from the public description.