<?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:36:46.788502+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/certfr-2026-avi-0281</id>
    <title>certfr-2026-avi-0281 — De multiples vulnérabilités ont été découvertes dans les produits Splunk. Certaines d'entre elles permettent à un attaq…</title>
    <updated>2026-10-12T23:36:46.793357+00:00</updated>
    <content>certfr-2026-avi-0281</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2026-avi-0281"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-260918</id>
    <title>EUVD-2026-260918</title>
    <updated>2026-10-12T23:36:46.793389+00:00</updated>
    <content>EUVD-2026-260918</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-260918"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2025-64182</id>
    <title>fkie_cve-2025-64182</title>
    <updated>2026-10-12T23:36:46.793404+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.2.0 through 3.2.4, 3.3.0 through 3.3.5, and 3.4.0 through 3.4.2, a memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects. Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit). Versions 3.2.5, 3.3.6, and 3.4.3 contain a patch for the issue.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2025-64182"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-vh63-9mqx-wmjr</id>
    <title>GHSA-vh63-9mqx-wmjr — OpenEXR has buffer overflow in PyOpenEXR_old's channels() and channel()</title>
    <updated>2026-10-12T23:36:46.793433+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: OpenEXR</p>
<p>### Summary</p>
<p>A memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects.</p>
<p>Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit).</p>
<p>This bug was found with [ZeroPath](https://zeropath.com/?utm_source=joshua.hu).</p>
<p>### Details</p>
<p>Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit), around [here](https://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L528-L536).</p>
<p>-   In `channel()`:</p>
<p>-   Width and height are derived from the header dataWindow using `int`.</p>
<p>-   `typeSize` is a `size_t`. The buffer size is computed as `typeSize * width * height` with no bounds checks.</p>
<p>-   The result is passed to `PyString_FromStringAndSize(NULL, size)` which maps to `PyBytes_FromStringAndSize`. That function expects `Py_ssize_t`. If the product overflows or exceeds `PY_SSIZE_T_MAX`, allocation fails or the value wraps.</p>
<p>-   The return value is not checked. The code immediately calls `PyString_AsString(r)` and proceeds to build a `FrameBuffer` and calls `readPixels(miny, maxy)`.</p>
<p>-   On 64 bit: `PyBytes_FromStringAndSize` returns NULL, the wrapper de…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-vh63-9mqx-wmjr"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2025:15741-1</id>
    <title>openSUSE-SU-2025:15741-1 — libIex-3_4-33-3.4.3-1.1 on GA media</title>
    <updated>2026-10-12T23:36:46.793486+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>libIex-3_4-33-3.4.3-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2025:15741-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/pysec-2026-2851</id>
    <title>PYSEC-2026-2851 — OpenEXR has buffer overflow in PyOpenEXR_old's channels() and channel()</title>
    <updated>2026-10-12T23:36:46.793504+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: openexr</p>
<p>### Summary</p>
<p>A memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects.</p>
<p>Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit).</p>
<p>This bug was found with [ZeroPath](https://zeropath.com/?utm_source=joshua.hu).</p>
<p>### Details</p>
<p>Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit), around [here](https://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXR_old.cpp#L528-L536).</p>
<p>-   In `channel()`:</p>
<p>-   Width and height are derived from the header dataWindow using `int`.</p>
<p>-   `typeSize` is a `size_t`. The buffer size is computed as `typeSize * width * height` with no bounds checks.</p>
<p>-   The result is passed to `PyString_FromStringAndSize(NULL, size)` which maps to `PyBytes_FromStringAndSize`. That function expects `Py_ssize_t`. If the product overflows or exceeds `PY_SSIZE_T_MAX`, allocation fails or the value wraps.</p>
<p>-   The return value is not checked. The code immediately calls `PyString_AsString(r)` and proceeds to build a `FrameBuffer` and calls `readPixels(miny, maxy)`.</p>
<p>-   On 64 bit: `PyBytes_FromStringAndSize` returns NULL, the wrapper de…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/pysec-2026-2851"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-64182</id>
    <title>Withdrawn: UBUNTU-CVE-2025-64182</title>
    <updated>2026-10-12T23:36:46.793547+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Withdrawn by the publisher.</strong></p>
<p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: openexr, Ubuntu:18.04:LTS: openexr, Ubuntu:Pro:20.04:LTS: openexr, Ubuntu:Pro:22.04:LTS: openexr, Ubuntu:24.04:LTS: openexr, Ubuntu:25.10: 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 versions 3.2.0 through 3.2.4, 3.3.0 through 3.3.5, and 3.4.0 through 3.4.2, a memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects. Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit). Versions 3.2.5, 3.3.6, and 3.4.3 contain a patch for the issue.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-64182"/>
  </entry>
</feed>
