OESA-2026-1844 (CVE-2026-34380)
Vulnerability from osv_openeuler – Published: 2026-04-11 11:10 – Updated: 2026-08-06 11:10 – Source websiteOpenEXR 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 provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a signed integer overflow exists in undo_pxr24_impl() in src/lib/OpenEXRCore/internal_pxr24.c at line 377. The expression (uint64_t)(w * 3) computes w * 3 as a signed 32-bit integer before casting to uint64_t. When w is large, this multiplication constitutes undefined behavior under the C standard. On tested builds (clang/gcc without sanitizers), two's-complement wraparound commonly occurs, and for specific values of w the wrapped result is a small positive integer, which may allow the subsequent bounds check to pass incorrectly. If the check is bypassed, the decoding loop proceeds to write pixel data through dout, potentially extending far beyond the allocated output buffer. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34380)
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, the DWA lossy decoder constructs temporary per-component block pointers using signed 32-bit arithmetic. For a large enough width, the calculation overflows and later decoder stores operate on a wrapped pointer outside the allocated rowBlock backing store. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34589)
| URL | Type | |
|---|---|---|
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"OpenEXR-3.1.5-6.oe2203sp4.aarch64.rpm",
"OpenEXR-debuginfo-3.1.5-6.oe2203sp4.aarch64.rpm",
"OpenEXR-debugsource-3.1.5-6.oe2203sp4.aarch64.rpm",
"OpenEXR-devel-3.1.5-6.oe2203sp4.aarch64.rpm",
"OpenEXR-libs-3.1.5-6.oe2203sp4.aarch64.rpm"
],
"src": [
"OpenEXR-3.1.5-6.oe2203sp4.src.rpm"
],
"x86_64": [
"OpenEXR-3.1.5-6.oe2203sp4.x86_64.rpm",
"OpenEXR-debuginfo-3.1.5-6.oe2203sp4.x86_64.rpm",
"OpenEXR-debugsource-3.1.5-6.oe2203sp4.x86_64.rpm",
"OpenEXR-devel-3.1.5-6.oe2203sp4.x86_64.rpm",
"OpenEXR-libs-3.1.5-6.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "OpenEXR",
"purl": "pkg:rpm/openEuler/OpenEXR\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.5-6.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Medium"
},
"details": "OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light \u0026amp;amp; Magic for use in computer imaging applications.\r\n\r\nSecurity Fix(es):\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a signed integer overflow exists in undo_pxr24_impl() in src/lib/OpenEXRCore/internal_pxr24.c at line 377. The expression (uint64_t)(w * 3) computes w * 3 as a signed 32-bit integer before casting to uint64_t. When w is large, this multiplication constitutes undefined behavior under the C standard. On tested builds (clang/gcc without sanitizers), two\u0026apos;s-complement wraparound commonly occurs, and for specific values of w the wrapped result is a small positive integer, which may allow the subsequent bounds check to pass incorrectly. If the check is bypassed, the decoding loop proceeds to write pixel data through dout, potentially extending far beyond the allocated output buffer. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34380)\n\nOpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, the DWA lossy decoder constructs temporary per-component block pointers using signed 32-bit arithmetic. For a large enough width, the calculation overflows and later decoder stores operate on a wrapped pointer outside the allocated rowBlock backing store. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34589)",
"id": "OESA-2026-1844",
"modified": "2026-08-06T11:10:51Z",
"published": "2026-04-11T11:10:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34380"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34589"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "OpenEXR security update",
"upstream": [
"CVE-2026-34380",
"CVE-2026-34589"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.