OESA-2026-4685

See a problem?
Please try reporting it to the source first.

Source

https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2026-4685

Import Source

https://repo.openeuler.org/security/data/osv/OESA-2026-4685.json

JSON Data

https://api.osv.dev/v1/vulns/OESA-2026-4685

Upstream

CVE (2)

Published

2026-11-04T13:54:28Z

Modified

2026-11-04T14:00:05Z

Severity

7.1 (High) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H CVSS Calculator

Summary

OpenEXR security update

Details

OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light & Magic for use in computer imaging applications.

Security Fix(es):

OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. OpenEXR versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 are vulnerable on ILP32 builds to an out-of-bounds read. The vulnerability is reached when a crafted uncompressed deep-tile EXR causes the sample-count table size calculation in OpenEXRCore decoding.c to wrap before unpack_sample_table() iterates over the full attacker-controlled tile dimensions, allowing denial of service. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.(CVE-2026-59983)

OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13, exrmultiview can write past a heap allocation when it combines two attacker-supplied, individually valid scanline EXR files whose union dataWindow is not aligned to one view's channel subsampling. The utility allocates sampled channel storage using a truncated union_width / xSampling, then reads the sampled input through a Slice based on the misaligned union window, producing a heap out-of-bounds write. The trigger is normal public-tool processing, such as exrmultiview left A.exr right B.exr out.exr with crafted but valid inputs, so this is not solely an API or caller-precondition issue. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.(CVE-2026-68515)

Database specific

{
    "severity": "High"
}

References

Affected packages

openEuler:24.03-LTS-SP4 / OpenEXR

Package

Name: OpenEXR
Purl: pkg:rpm/openEuler/OpenEXR&distro=openEuler-24.03-LTS-SP4

Affected ranges

Type: ECOSYSTEM
Events: Introduced

0 Unknown introduced version / All previous versions are affected

Fixed

3.1.11-10.oe2403sp4

Ecosystem specific

{
    "aarch64": [
        "OpenEXR-3.1.11-10.oe2403sp4.aarch64.rpm",
        "OpenEXR-debuginfo-3.1.11-10.oe2403sp4.aarch64.rpm",
        "OpenEXR-debugsource-3.1.11-10.oe2403sp4.aarch64.rpm",
        "OpenEXR-devel-3.1.11-10.oe2403sp4.aarch64.rpm",
        "OpenEXR-libs-3.1.11-10.oe2403sp4.aarch64.rpm"
    ],
    "src": [
        "OpenEXR-3.1.11-10.oe2403sp4.src.rpm"
    ],
    "x86_64": [
        "OpenEXR-3.1.11-10.oe2403sp4.x86_64.rpm",
        "OpenEXR-debuginfo-3.1.11-10.oe2403sp4.x86_64.rpm",
        "OpenEXR-debugsource-3.1.11-10.oe2403sp4.x86_64.rpm",
        "OpenEXR-devel-3.1.11-10.oe2403sp4.x86_64.rpm",
        "OpenEXR-libs-3.1.11-10.oe2403sp4.x86_64.rpm"
    ]
}

Database specific

source

"https://repo.openeuler.org/security/data/osv/OESA-2026-4685.json"