{
  "affected": [
    {
      "ranges": [
        {
          "database_specific": {
            "cpe": "cpe:2.3:a:openexr:openexr:*:*:*:*:*:*:*:*",
            "extracted_events": [
              {
                "introduced": "3.4.0"
              },
              {
                "fixed": "3.4.11"
              },
              {
                "fixed": "3.4.12"
              }
            ],
            "source": [
              "AFFECTED_FIELD",
              "CPE_RANGE",
              "REFERENCES"
            ]
          },
          "events": [
            {
              "introduced": "20a65852895894434bea88613f6d29ac8e88bd6e"
            },
            {
              "fixed": "d25e2a83b5a5f0eb9e350de8218fa27c348da203"
            }
          ],
          "repo": "https://github.com/academysoftwarefoundation/openexr",
          "type": "GIT"
        }
      ]
    }
  ],
  "aliases": [
    "GHSA-gjpj-qv64-vwhf"
  ],
  "database_specific": {
    "cna_assigner": "GitHub_M",
    "cwe_ids": [
      "CWE-122"
    ],
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45696.json"
  },
  "details": "OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, the HTJ2K (High-Throughput JPEG 2000) decoder, ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The  ht_undo_imp function copies decoded pixels out of a per-line OpenJPH buffer using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can declare different (smaller) tile/line dimensions than the EXR header advertises, but ht_undo_impl() does not validate this — it pulls width 32-bit samples from cur_line-\u003ei32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.",
  "id": "CVE-2026-45696",
  "modified": "2026-07-16T03:31:03.649819536Z",
  "published": "2026-06-18T20:31:56.603Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.4.12"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-45696.json"
    },
    {
      "type": "ADVISORY",
      "url": "https://access.redhat.com/security/cve/CVE-2026-45696"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/AcademySoftwareFoundation/openexr/security/advisories/GHSA-gjpj-qv64-vwhf"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45696.json"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45696"
    },
    {
      "type": "REPORT",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2490597"
    }
  ],
  "schema_version": "1.8.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenEXR HTJ2K decoder heap buffer over-read in ht_undo_impl() (DoS)"
}