OpenEXR has HTJ2K Signed Integer Overflow in ht_undo_impl()
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. Versions 3.4.0 through 3.4.9 have a signed integer overflow vulnerability in OpenEXR's HTJ2K (High-Throughput JPEG 2000) decompression path. The `ht_undo_impl()` function in `src/lib/OpenEXRCore/internal_ht.cpp` accumulates a bytes-per-line value (`bpl`) using a 32-bit signed integer with no overflow guard. A crafted EXR file with 16,385 FLOAT channels at the HTJ2K maximum width of 32,767 causes `bpl` to overflow `INT_MAX`, producing undefined behavior confirmed by UBSan. On an allocator-permissive host where the required ~64 GB allocation succeeds, the wrapped negative `bpl` value would subsequently be used as a per-scanline pointer advance, which would produce a heap out-of-bounds write. On a memory-constrained host, the allocation fails before `ht_undo_impl()` is entered. This is the second distinct integer overflow in `ht_undo_impl()`. CVE-2026-34545 addressed a different overflow in the same function — the `int16_t p` pixel-loop counter at line ~302 that overflows when iterating over channels whose `width` exceeds 32,767. The CVE-2026-34545 fix did not touch the `int bpl` accumulator at line 211, which is the subject of this advisory. The `bpl` accumulator was also not addressed by any of the 8 advisories in the 2026-04-05 v3.4.9 release batch. This finding is structurally identical to CVE-2026-34588 (PIZ `wcount*nx` overflow in
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-39886
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 10:26 UTC · Revision 1
Source evidence
OpenEXR has HTJ2K Signed Integer Overflow in ht_undo_impl()
core-osv · Original sourcePublished 21 Apr 2026, 01:27 UTC
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. Versions 3.4.0 through 3.4.9 have a signed integer overflow vulnerability in OpenEXR's HTJ2K (High-Throughput JPEG 2000) decompression path. The `ht_undo_impl()` function in `src/lib/OpenEXRCore/internal_ht.cpp` accumulates a bytes-per-line value (`bpl`) using a 32-bit signed integer with no overflow guard. A crafted EXR file with 16,385 FLOAT channels at the HTJ2K maximum width of 32,767 causes `bpl` to overflow `INT_MAX`, producing undefined behavior confirmed by UBSan. On an allocator-permissive host where the required ~64 GB allocation succeeds, the wrapped negative `bpl` value would subsequently be used as a per-scanline pointer advance, which would produce a heap out-of-bounds write. On a memory-constrained host, the allocation fails before `ht_undo_impl()` is entered. This is the second distinct integer overflow in `ht_undo_impl()`. CVE-2026-34545 addressed a different overflow in the same function — the `int16_t p` pixel-loop counter at line ~302 that overflows when iterating over channels whose `width` exceeds 32,767. The CVE-2026-34545 fix did not touch the `int bpl` accumulator at line 211, which is the subject of this advisory. The `bpl` accumulator was also not addressed by any of the 8 advisories in the 2026-04-05 v3.4.9 release batch. This finding is structurally identical to CVE-2026-34588 (PIZ `wcount*nx` overflow in
osv:CVE-2026-39886
Complete source record
{
"id": "106a9f142cfc87e814a9eaaffda1cf1b235cbf9c0200ccbb9f66d19e8e6a3c3b",
"url": "https://osv.dev/vulnerability/CVE-2026-39886",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "OpenEXR has HTJ2K Signed Integer Overflow in ht_undo_impl()",
"summary": "OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. Versions 3.4.0 through 3.4.9 have a signed integer overflow vulnerability in OpenEXR's HTJ2K (High-Throughput JPEG 2000) decompression path. The `ht_undo_impl()` function in `src/lib/OpenEXRCore/internal_ht.cpp` accumulates a bytes-per-line value (`bpl`) using a 32-bit signed integer with no overflow guard. A crafted EXR file with 16,385 FLOAT channels at the HTJ2K maximum width of 32,767 causes `bpl` to overflow `INT_MAX`, producing undefined behavior confirmed by UBSan. On an allocator-permissive host where the required ~64 GB allocation succeeds, the wrapped negative `bpl` value would subsequently be used as a per-scanline pointer advance, which would produce a heap out-of-bounds write. On a memory-constrained host, the allocation fails before `ht_undo_impl()` is entered. This is the second distinct integer overflow in `ht_undo_impl()`. CVE-2026-34545 addressed a different overflow in the same function — the `int16_t p` pixel-loop counter at line ~302 that overflows when iterating over channels whose `width` exceeds 32,767. The CVE-2026-34545 fix did not touch the `int bpl` accumulator at line 211, which is the subject of this advisory. The `bpl` accumulator was also not addressed by any of the 8 advisories in the 2026-04-05 v3.4.9 release batch. This finding is structurally identical to CVE-2026-34588 (PIZ `wcount*nx` overflow in",
"evidence": "osv:CVE-2026-39886",
"products": [],
"severity": "medium",
"structured": {
"id": "CVE-2026-39886",
"aliases": [
"CVE-2026-39886",
"GHSA-r3mr-mx8q-jcw5"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/academysoftwarefoundation/openexr",
"type": "GIT",
"events": [
{
"introduced": "20a65852895894434bea88613f6d29ac8e88bd6e"
},
{
"fixed": "67de2bffbd7da508f75fbdc56e6e551a4e31fb83"
}
],
"database_specific": {
"extracted_events": [
{
"range": [
{
"introduced": "3.4.0"
},
{
"fixed": "3.4.10"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StringRangeExpression"
},
{
"range": [
{
"fixed": "67de2bffbd7da508f75fbdc56e6e551a4e31fb83"
}
],
"source": "REFERENCES_TAG",
"original_tag": "v3.4.10"
},
{
"cpe": "cpe:2.3:a:openexr:openexr:*:*:*:*:*:*:*:*",
"range": [
{
"introduced": "3.4.0"
},
{
"fixed": "3.4.10"
}
],
"source": "CPE_RANGE"
}
]
}
}
],
"versions": [
"v3.4.9",
"v3.4.9-rc",
"v3.4.8-rc",
"v3.4.8",
"v3.4.7",
"v3.4.7-rc",
"v3.4.6",
"v3.4.6-rc",
"v3.4.5",
"v3.4.5-rc",
"v3.4.4-rc2",
"v3.4.4",
"v3.4.4-rc",
"v3.4.3-rc3",
"v3.4.3",
"v3.4.3-rc2",
"v3.4.3-rc",
"v3.4.2-rc2",
"v3.4.2",
"v3.4.2-rc",
"v3.4.1-rc2",
"v3.4.1",
"v3.4.1-rc",
"v3.4.0"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-39886.json"
}
}
],
"modified": "2026-10-28T02:30:27.868164264Z",
"provider": "osv",
"references": [
"https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.4.10",
"https://github.com/AcademySoftwareFoundation/openexr/security/advisories/GHSA-r3mr-mx8q-jcw5",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/39xxx/CVE-2026-39886.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-39886"
],
"provider_metadata": {
"cwe_ids": [
"CWE-190"
],
"cna_assigner": "GitHub_M",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/39xxx/CVE-2026-39886.json"
}
},
"related_cves": [
{
"value": "CVE-2026-39886",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 494501,
"published_at": "2026-04-21T01:27:01.371+00:00"
}