Nixpkgs security tracker

Login with GitHub

Suggestions search

With package: openexr

Found 4 matching suggestions

View:
Compact
Detailed
Permalink CVE-2026-39886
5.3 MEDIUM
  • CVSS version: 3.1
  • Attack vector (AV): NETWORK
  • Attack complexity (AC): LOW
  • Privileges required (PR): NONE
  • User interaction (UI): NONE
  • Scope (S): UNCHANGED
  • Confidentiality impact (C): NONE
  • Integrity impact (I): NONE
  • Availability impact (A): LOW
updated 6 hours ago by @LeSuisse Activity log
  • Created automatic suggestion
  • @LeSuisse ignored
    3 packages
    • openexr_2
    • openexrid-unstable
    • haskellPackages.openexr-write
  • @LeSuisse dismissed
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 `internal_piz.c`) and should be remediated with the same pattern. The CVE-2026-34588 fix did not touch `internal_ht.cpp`. Version 3.4.10 contains a remediation that addresses the vulnerability in `internal_ht.cpp`.

Affected products

openexr
  • ==>= 3.4.0, < 3.4.10

Matching in nixpkgs

pkgs.openexr

High dynamic-range (HDR) image file format

Ignored packages (3)

Package maintainers

Not impacted we have not yet upgraded to 3.4.x
updated 2 weeks, 6 days ago by @LeSuisse Activity log
  • Created automatic suggestion
  • @LeSuisse ignored
    3 packages
    • openexr_2
    • openexrid-unstable
    • haskellPackages.openexr-write
  • @LeSuisse dismissed
OpenEXR: integer overflow to OOB write in uncompress_b44_impl()

OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From version 3.4.0 to before version 3.4.8, a crafted B44 or B44A EXR file can cause an out-of-bounds write in any application that decodes it via exr_decoding_run(). Consequences range from immediate crash (most likely) to corruption of adjacent heap allocations (layout-dependent). This issue has been patched in version 3.4.8.

Affected products

openexr
  • ==>= 3.4.0, < 3.4.8

Matching in nixpkgs

pkgs.openexr

High dynamic-range (HDR) image file format

Ignored packages (3)

Package maintainers

Not in the range of impacted version.
updated 2 weeks, 6 days ago by @LeSuisse Activity log
  • Created automatic suggestion
  • @LeSuisse ignored
    3 packages
    • openexr_2
    • openexrid-unstable
    • haskellPackages.openexr-write
  • @LeSuisse dismissed
OpenEXR: integer overflow lead to OOB in HTJ2K decoder

OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From version 3.4.0 to before version 3.4.7, an attacker providing a crafted .exr file with HTJ2K compression and a channel width of 32768 can write controlled data beyond the output heap buffer in any application that decodes EXR images. The write primitive is 2 bytes per overflow iteration or 4 bytes (by another path), repeating for each additional pixel past the overflow point. In this context, a heap write overflow can lead to remote code execution on systems. This issue has been patched in version 3.4.7.

Affected products

openexr
  • ==>= 3.4.0, < 3.4.7

Matching in nixpkgs

pkgs.openexr

High dynamic-range (HDR) image file format

Ignored packages (3)

Package maintainers

Not in the range of impacted version
updated 2 weeks, 6 days ago by @LeSuisse Activity log
  • Created automatic suggestion
  • @LeSuisse ignored
    3 packages
    • openexrid-unstable
    • haskellPackages.openexr-write
    • openexr_2
  • @LeSuisse dismissed
OpenEXR: Heap information disclosure in PXR24 decompression via unchecked decompressed size (undo_pxr24_impl)

OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From version 3.4.0 to before version 3.4.8, sensitive information from heap memory may be leaked through the decoded pixel data (information disclosure). This occurs under default settings; simply reading a malicious EXR file is sufficient to trigger the issue, without any user interaction. This issue has been patched in version 3.4.8.

Affected products

openexr
  • ==>= 3.4.0, < 3.4.8

Matching in nixpkgs

pkgs.openexr

High dynamic-range (HDR) image file format

Ignored packages (3)

Package maintainers

Not in the range of impacted version.