https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 14:28:14 +0000 https://cve.radiocsirt.org/vuln/alsa-2026:7682 <p><strong>Affected:</strong> AlmaLinux:10: openexr, AlmaLinux:10: openexr-devel, AlmaLinux:10: openexr-libs</p> <p>OpenEXR is an open-source high-dynamic-range floating-point image file format for high-quality image processing and storage. This document presents a brief overview of OpenEXR and explains concepts that are specific to this format. This package containes the binaries for OpenEXR.</p> <p>Security Fix(es):</p> <p>* openexr: OpenEXR: Arbitrary code execution via integer overflow in EXR file processing (CVE-2026-27622)</p> <p>For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</p> <p><strong>Affected:</strong> AlmaLinux:10: openexr, AlmaLinux:10: openexr-devel, AlmaLinux:10: openexr-libs</p> <p>OpenEXR is an open-source high-dynamic-range floating-point image file format for high-quality image processing and storage. This document presents a brief overview of OpenEXR and explains concepts that are specific to this format. This package containes the binaries for OpenEXR.</p> <p>Security Fix(es):</p> <p>* openexr: OpenEXR: Arbitrary code execution via integer overflow in EXR file processing (CVE-2026-27622)</p> <p>For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</p> https://cve.radiocsirt.org/vuln/alsa-2026:7682 https://cve.radiocsirt.org/vuln/bdu:2026-12077 bdu:2026-12077 https://cve.radiocsirt.org/vuln/bdu:2026-12077 https://cve.radiocsirt.org/vuln/euvd-2026-365477 EUVD-2026-365477 https://cve.radiocsirt.org/vuln/euvd-2026-365477 https://cve.radiocsirt.org/vuln/fkie_cve-2026-27622 <p>OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In CompositeDeepScanLine::readPixels, per-pixel totals are accumulated in vector&lt;unsigned int&gt; total_sizes for attacker-controlled large counts across many parts, total_sizes[ptr] wraps modulo 2^32. overall_sample_count is then derived from wrapped totals and used in samples[channel].resize(overall_sample_count). Decode pointer setup/consumption proceeds with true sample counts, and write operations in core unpack (generic_unpack_deep_pointers) overrun the undersized composite sample buffer. This vulnerability is fixed in v3.2.6, v3.3.8, and v3.4.6.</p> <p>OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In CompositeDeepScanLine::readPixels, per-pixel totals are accumulated in vector&lt;unsigned int&gt; total_sizes for attacker-controlled large counts across many parts, total_sizes[ptr] wraps modulo 2^32. overall_sample_count is then derived from wrapped totals and used in samples[channel].resize(overall_sample_count). Decode pointer setup/consumption proceeds with true sample counts, and write operations in core unpack (generic_unpack_deep_pointers) overrun the undersized composite sample buffer. This vulnerability is fixed in v3.2.6, v3.3.8, and v3.4.6.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-27622 https://cve.radiocsirt.org/vuln/ghsa-cr4v-6jm6-4963 <p><strong>Affected:</strong> PyPI: OpenEXR</p> <p>## Summary</p> <p>Function: `CompositeDeepScanLine::readPixels`, reachable from high-level multipart deep read flows (`MultiPartInputFile` + `DeepScanLineInputPart` + `CompositeDeepScanLine`).</p> <p>Vulnerable lines (`src/lib/OpenEXR/ImfCompositeDeepScanLine.cpp`): - `total_sizes[ptr] += counts[j][ptr];` (line ~511) - `overall_sample_count += total_sizes[ptr];` (line ~514) - `samples[channel].resize (overall_sample_count);` (line ~535)</p> <p>Impact: 32-bit sample-count accumulation wrap leads to undersized allocation, then decode writes with true sample volume, causing heap OOB write in `generic_unpack_deep_pointers` (`src/lib/OpenEXRCore/unpack.c:1374`) (DoS/Crash, memory corruption/RCE).</p> <p>Attack scenario: - Attacker provides multipart deep EXR with many parts and very large sample counts per pixel. - Uses compression (RLE/ZIPS) to keep file size relatively small vs decode pressure. - The overflow happens in composite sample accounting (`unsigned int`), while pointer progression for decode uses larger counters and reaches out-of-bounds.</p> <p>Tested on: `OpenEXR 4.0.0-dev` (commit 83449669402080874b25ff1fa740649a9e6ea064) but this code has existed since v2.3.0</p> <p>## Steps to reproduce</p> <p>[composite_deepscanline_poc_bundle.patch](https://github.com/user-attachments/files/25383205/composite_deepscanline_poc_bundle.patch)</p> <p>PoC files used: - Writer/generator: `poc/composite_deep_scanline_e2e_compressed_poc.cpp` - Minimal high-level reader harness: `poc/simple_exr_reader.cpp`</p> <p>The reader harness intenti…</p> <p><strong>Affected:</strong> PyPI: OpenEXR</p> <p>## Summary</p> <p>Function: `CompositeDeepScanLine::readPixels`, reachable from high-level multipart deep read flows (`MultiPartInputFile` + `DeepScanLineInputPart` + `CompositeDeepScanLine`).</p> <p>Vulnerable lines (`src/lib/OpenEXR/ImfCompositeDeepScanLine.cpp`): - `total_sizes[ptr] += counts[j][ptr];` (line ~511) - `overall_sample_count += total_sizes[ptr];` (line ~514) - `samples[channel].resize (overall_sample_count);` (line ~535)</p> <p>Impact: 32-bit sample-count accumulation wrap leads to undersized allocation, then decode writes with true sample volume, causing heap OOB write in `generic_unpack_deep_pointers` (`src/lib/OpenEXRCore/unpack.c:1374`) (DoS/Crash, memory corruption/RCE).</p> <p>Attack scenario: - Attacker provides multipart deep EXR with many parts and very large sample counts per pixel. - Uses compression (RLE/ZIPS) to keep file size relatively small vs decode pressure. - The overflow happens in composite sample accounting (`unsigned int`), while pointer progression for decode uses larger counters and reaches out-of-bounds.</p> <p>Tested on: `OpenEXR 4.0.0-dev` (commit 83449669402080874b25ff1fa740649a9e6ea064) but this code has existed since v2.3.0</p> <p>## Steps to reproduce</p> <p>[composite_deepscanline_poc_bundle.patch](https://github.com/user-attachments/files/25383205/composite_deepscanline_poc_bundle.patch)</p> <p>PoC files used: - Writer/generator: `poc/composite_deep_scanline_e2e_compressed_poc.cpp` - Minimal high-level reader harness: `poc/simple_exr_reader.cpp`</p> <p>The reader harness intenti…</p> https://cve.radiocsirt.org/vuln/ghsa-cr4v-6jm6-4963 https://cve.radiocsirt.org/vuln/oesa-2026-1616 <p><strong>Affected:</strong> openEuler:24.03-LTS: OpenEXR</p> <p>OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light &amp;amp;amp; Magic for use in computer imaging applications. Security Fix(es):</p> <p>OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In CompositeDeepScanLine::readPixels, per-pixel totals are accumulated in vector&amp;lt;unsigned int&amp;gt; total_sizes for attacker-controlled large counts across many parts, total_sizes[ptr] wraps modulo 2^32. overall_sample_count is then derived from wrapped totals and used in samples[channel].resize(overall_sample_count). Decode pointer setup/consumption proceeds with true sample counts, and write operations in core unpack (generic_unpack_deep_pointers) overrun the undersized composite sample buffer. This vulnerability is fixed in v3.2.6, v3.3.8, and v3.4.6.(CVE-2026-27622)</p> <p><strong>Affected:</strong> openEuler:24.03-LTS: OpenEXR</p> <p>OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light &amp;amp;amp; Magic for use in computer imaging applications. Security Fix(es):</p> <p>OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In CompositeDeepScanLine::readPixels, per-pixel totals are accumulated in vector&amp;lt;unsigned int&amp;gt; total_sizes for attacker-controlled large counts across many parts, total_sizes[ptr] wraps modulo 2^32. overall_sample_count is then derived from wrapped totals and used in samples[channel].resize(overall_sample_count). Decode pointer setup/consumption proceeds with true sample counts, and write operations in core unpack (generic_unpack_deep_pointers) overrun the undersized composite sample buffer. This vulnerability is fixed in v3.2.6, v3.3.8, and v3.4.6.(CVE-2026-27622)</p> https://cve.radiocsirt.org/vuln/oesa-2026-1616 https://cve.radiocsirt.org/vuln/opensuse-su-2026:10303-1 <p>libIex-3_4-33-3.4.6-1.1 on GA media</p> <p>libIex-3_4-33-3.4.6-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:10303-1 https://cve.radiocsirt.org/vuln/pysec-2026-2846 <p><strong>Affected:</strong> PyPI: openexr</p> <p>## Summary</p> <p>Function: `CompositeDeepScanLine::readPixels`, reachable from high-level multipart deep read flows (`MultiPartInputFile` + `DeepScanLineInputPart` + `CompositeDeepScanLine`).</p> <p>Vulnerable lines (`src/lib/OpenEXR/ImfCompositeDeepScanLine.cpp`): - `total_sizes[ptr] += counts[j][ptr];` (line ~511) - `overall_sample_count += total_sizes[ptr];` (line ~514) - `samples[channel].resize (overall_sample_count);` (line ~535)</p> <p>Impact: 32-bit sample-count accumulation wrap leads to undersized allocation, then decode writes with true sample volume, causing heap OOB write in `generic_unpack_deep_pointers` (`src/lib/OpenEXRCore/unpack.c:1374`) (DoS/Crash, memory corruption/RCE).</p> <p>Attack scenario: - Attacker provides multipart deep EXR with many parts and very large sample counts per pixel. - Uses compression (RLE/ZIPS) to keep file size relatively small vs decode pressure. - The overflow happens in composite sample accounting (`unsigned int`), while pointer progression for decode uses larger counters and reaches out-of-bounds.</p> <p>Tested on: `OpenEXR 4.0.0-dev` (commit 83449669402080874b25ff1fa740649a9e6ea064) but this code has existed since v2.3.0</p> <p>## Steps to reproduce</p> <p>[composite_deepscanline_poc_bundle.patch](https://github.com/user-attachments/files/25383205/composite_deepscanline_poc_bundle.patch)</p> <p>PoC files used: - Writer/generator: `poc/composite_deep_scanline_e2e_compressed_poc.cpp` - Minimal high-level reader harness: `poc/simple_exr_reader.cpp`</p> <p>The reader harness intenti…</p> <p><strong>Affected:</strong> PyPI: openexr</p> <p>## Summary</p> <p>Function: `CompositeDeepScanLine::readPixels`, reachable from high-level multipart deep read flows (`MultiPartInputFile` + `DeepScanLineInputPart` + `CompositeDeepScanLine`).</p> <p>Vulnerable lines (`src/lib/OpenEXR/ImfCompositeDeepScanLine.cpp`): - `total_sizes[ptr] += counts[j][ptr];` (line ~511) - `overall_sample_count += total_sizes[ptr];` (line ~514) - `samples[channel].resize (overall_sample_count);` (line ~535)</p> <p>Impact: 32-bit sample-count accumulation wrap leads to undersized allocation, then decode writes with true sample volume, causing heap OOB write in `generic_unpack_deep_pointers` (`src/lib/OpenEXRCore/unpack.c:1374`) (DoS/Crash, memory corruption/RCE).</p> <p>Attack scenario: - Attacker provides multipart deep EXR with many parts and very large sample counts per pixel. - Uses compression (RLE/ZIPS) to keep file size relatively small vs decode pressure. - The overflow happens in composite sample accounting (`unsigned int`), while pointer progression for decode uses larger counters and reaches out-of-bounds.</p> <p>Tested on: `OpenEXR 4.0.0-dev` (commit 83449669402080874b25ff1fa740649a9e6ea064) but this code has existed since v2.3.0</p> <p>## Steps to reproduce</p> <p>[composite_deepscanline_poc_bundle.patch](https://github.com/user-attachments/files/25383205/composite_deepscanline_poc_bundle.patch)</p> <p>PoC files used: - Writer/generator: `poc/composite_deep_scanline_e2e_compressed_poc.cpp` - Minimal high-level reader harness: `poc/simple_exr_reader.cpp`</p> <p>The reader harness intenti…</p> https://cve.radiocsirt.org/vuln/pysec-2026-2846 https://cve.radiocsirt.org/vuln/rhsa-2026:12338 <p>openexr: OpenEXR: Arbitrary code execution via integer overflow in EXR file processing</p> <p>openexr: OpenEXR: Arbitrary code execution via integer overflow in EXR file processing</p> https://cve.radiocsirt.org/vuln/rhsa-2026:12338 https://cve.radiocsirt.org/vuln/suse-su-2026:20936-1 <p>Security update for openexr</p> <p>Security update for openexr</p> https://cve.radiocsirt.org/vuln/suse-su-2026:20936-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-27622 <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: openexr, Ubuntu:Pro:18.04:LTS: openexr, Ubuntu:Pro:20.04:LTS: openexr, Ubuntu:Pro:22.04:LTS: openexr, Ubuntu:Pro:24.04:LTS: openexr, Ubuntu:25.10: openexr, Ubuntu:Pro:26.04:LTS: openexr</p> <p>OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In CompositeDeepScanLine::readPixels, per-pixel totals are accumulated in vector&lt;unsigned int&gt; total_sizes for attacker-controlled large counts across many parts, total_sizes[ptr] wraps modulo 2^32. overall_sample_count is then derived from wrapped totals and used in samples[channel].resize(overall_sample_count). Decode pointer setup/consumption proceeds with true sample counts, and write operations in core unpack (generic_unpack_deep_pointers) overrun the undersized composite sample buffer. This vulnerability is fixed in v3.2.6, v3.3.8, and v3.4.6.</p> <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: openexr, Ubuntu:Pro:18.04:LTS: openexr, Ubuntu:Pro:20.04:LTS: openexr, Ubuntu:Pro:22.04:LTS: openexr, Ubuntu:Pro:24.04:LTS: openexr, Ubuntu:25.10: openexr, Ubuntu:Pro:26.04:LTS: openexr</p> <p>OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In CompositeDeepScanLine::readPixels, per-pixel totals are accumulated in vector&lt;unsigned int&gt; total_sizes for attacker-controlled large counts across many parts, total_sizes[ptr] wraps modulo 2^32. overall_sample_count is then derived from wrapped totals and used in samples[channel].resize(overall_sample_count). Decode pointer setup/consumption proceeds with true sample counts, and write operations in core unpack (generic_unpack_deep_pointers) overrun the undersized composite sample buffer. This vulnerability is fixed in v3.2.6, v3.3.8, and v3.4.6.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-27622 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1053 <p>Ein lokaler Angreifer kann eine Schwachstelle in Red Hat Enterprise Linux ausnutzen, um möglicherweise beliebigen Code auszuführen oder einen Denial-of-Service-Zustand zu verursachen.</p> <p>Ein lokaler Angreifer kann eine Schwachstelle in Red Hat Enterprise Linux ausnutzen, um möglicherweise beliebigen Code auszuführen oder einen Denial-of-Service-Zustand zu verursachen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1053