Nixpkgs security tracker

Login with GitHub
⚠️ You are using a production deployment that is still only suitable for demo purposes. Any work done in this might be wiped later without notice.

Suggestion detail

Untriaged
Permalink CVE-2026-68515
7.1 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): Required (R)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): None (N)
  • Integrity (I): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): Required (R)
  • Modified Confidentiality (MC): None (N)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): High (H)
created 4 days, 7 hours ago Activity log
  • Created suggestion
OpenEXR: Heap out-of-bounds write in exrmultiview with subsampled channel union

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.

Affected products

openexr
  • ==>= 3.4.0, < 3.4.14
  • ==< 3.2.11
  • ==>= 3.3.0, < 3.3.13

Matching in nixpkgs

Package maintainers