<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-12T23:06:14.878556+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2025-48072</id>
    <title>CVE-2025-48072 — OpenEXR's Inaccurate Pointer Arithmetic can Cause an Out of Bounds Heap</title>
    <updated>2026-10-12T23:06:14.880302+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> AcademySoftwareFoundation openexr</p>
<p>OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. Version 3.3.2 is vulnerable to a heap-based buffer overflow during a read operation due to bad pointer math when decompressing DWAA-packed scan-line EXR files with a maliciously forged chunk. This is fixed in version 3.3.3.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2025-48072"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-4r7w-q3jg-ff43</id>
    <title>GHSA-4r7w-q3jg-ff43 — OpenEXR Out of Bounds Heap Read due to Bad Pointer Arithmetic in LossyDctDecoder_execute</title>
    <updated>2026-10-12T23:06:14.880362+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: OpenEXR</p>
<p>### Summary
The OpenEXRCore code is vulnerable to a heap-based buffer overflow during a read operation due to bad pointer math when decompressing DWAA-packed scan-line EXR files with a maliciously forged chunk.</p>
<p>### Details</p>
<p>In the `LossyDctDecoder_execute` function (from `src/lib/OpenEXRCore/internal_dwa_decoder.h`, when SSE2 is enabled), the following code is used to copy data from the chunks:</p>
<p>```cpp
// no-op conversion to linear
for (int y = 8 * blocky; y &lt; 8 * blocky + maxY; ++y)
{
    __m128i* restrict dst = (__m128i *) chanData[comp]-&gt;_rows[y];
    __m128i const * restrict src = (__m128i const *)&amp;rowBlock[comp][(y &amp; 0x7) * 8];</p>
<p>for (int blockx = 0; blockx &lt; numFullBlocksX; ++blockx)
    {
        _mm_storeu_si128 (dst, _mm_loadu_si128 (src)); //</p>
<p>src += 8 * 8; // &lt;--- si128 pointer incremented as a uint16_t
        dst += 8;
    }
}
```</p>
<p>The issue arises because the `src` pointer, which is a `si128` pointer, is incremented by `8*8`, as if it were a `uint16_t` pointer (64 * uint16_t == 128 bytes). In non-block aligned chunks (width/height not a multiple of 8), this can cause `src` to point past the boundaries of the chunk.</p>
<p>### PoC</p>
<p>In order to reproduce the PoC with fidelity and avoid undefined behaviors, it is necessary to enable ASAN (and SSE2). Otherwise the out-of-bound read will not be detected until its side-effect causes a crash.</p>
<p>NOTE: please download the `dwadecoder_crash.exr` file from the following link:</p>
<p>https://github.com/ShielderSec/poc/tree…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-4r7w-q3jg-ff43"/>
  </entry>
</feed>
