<?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-04T10:30:53.610554+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/bdu:2025-12797</id>
    <title>bdu:2025-12797</title>
    <updated>2026-10-04T10:30:54.025720+00:00</updated>
    <content>bdu:2025-12797</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2025-12797"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2025-avi-1036</id>
    <title>certfr-2025-avi-1036 — De multiples vulnérabilités ont été découvertes dans les produits VMware. Elles permettent à un attaquant de provoquer…</title>
    <updated>2026-10-04T10:30:54.025799+00:00</updated>
    <content>certfr-2025-avi-1036</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2025-avi-1036"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cleanstart-2026-uk11362</id>
    <title>CLEANSTART-2026-UK11362 — Security fix for CVE-2025-58058 applied in: gitness 3.3.0-r2, gptscript 0.6.0-r0, gptscript 0.7.1-r0, gptscript 0.8.5-r0</title>
    <updated>2026-10-04T10:30:54.025824+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> CleanStart: gitness, CleanStart: gptscript</p>
<p>CVE-2025-58058 affects multiple packages. This issue is resolved in later releases. See references for individual vulnerability details.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cleanstart-2026-uk11362"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-251362</id>
    <title>EUVD-2026-251362</title>
    <updated>2026-10-04T10:30:54.025863+00:00</updated>
    <content>EUVD-2026-251362</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-251362"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2025-58058</id>
    <title>fkie_cve-2025-58058</title>
    <updated>2026-10-04T10:30:54.025876+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>xz is a pure golang package for reading and writing xz-compressed files. Prior to version 0.5.14, it is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the specification. Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. This issue has been patched in version 0.5.14.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2025-58058"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-jc7w-c686-c4v9</id>
    <title>GHSA-jc7w-c686-c4v9 — github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives</title>
    <updated>2026-10-04T10:30:54.025905+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/ulikunitz/xz</p>
<p>### Summary</p>
<p>It is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has  a checksum to detect such an issue according to the [specification](https://github.com/jljusten/LZMA-SDK/blob/master/DOC/lzma-specification.txt).</p>
<p>Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done.</p>
<p>### Mitigations</p>
<p>The release v0.5.15 includes following mitigations:</p>
<p>- The ReaderConfig DictCap field is now interpreted as a limit for the dictionary size.
- The default is 2 Gigabytes - 1 byte (2^31-1 bytes).
- Users can check with the [Reader.Header] method what the actual values are in  their LZMA files and set a smaller limit using ReaderConfig.
- The dictionary size will not exceed the larger of the file size and the minimum dictionary size. This is another measure to prevent huge memory allocations for the dictionary.
- The code supports stream sizes only up to a pebibyte (1024^5).</p>
<p>Note that the original v0.5.14 version had a compiler error for 32 bit platforms, which has been fixed by v0.5.15.</p>
<p>### Methods affected</p>
<p>Only software that uses [lzma.NewReader](https://pkg.go.dev/github.com/ulikunitz/xz/lzma#NewReader) or [lzma.ReaderConfig.NewReader](http…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-jc7w-c686-c4v9"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2025-58058</id>
    <title>msrc_CVE-2025-58058 — github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives</title>
    <updated>2026-10-04T10:30:54.025956+00:00</updated>
    <content>msrc_CVE-2025-58058</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2025-58058"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2025:15503-1</id>
    <title>openSUSE-SU-2025:15503-1 — tailscale-1.86.5-1.1 on GA media</title>
    <updated>2026-10-04T10:30:54.025976+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>tailscale-1.86.5-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2025:15503-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/rhsa-2026:26254</id>
    <title>RHSA-2026:26254 — Red Hat Security Advisory: Assisted Installer RHEL 9 components for Multicluster Engine for Kubernetes 2.8.8</title>
    <updated>2026-10-04T10:30:54.025994+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>github.com/ulikunitz/xz: github.com/ulikunitz/xz leaks memory github.com/open-telemetry/opentelemetry-go: OpenTelemetry-Go: Arbitrary code execution via PATH hijacking on BSD/Solaris</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/rhsa-2026:26254"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2025:03448-1</id>
    <title>SUSE-SU-2025:03448-1 — Security update for warewulf4</title>
    <updated>2026-10-04T10:30:54.026014+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for warewulf4</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2025:03448-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-58058</id>
    <title>UBUNTU-CVE-2025-58058</title>
    <updated>2026-10-04T10:30:54.026029+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:20.04:LTS: golang-github-ulikunitz-xz, Ubuntu:22.04:LTS: golang-github-ulikunitz-xz, Ubuntu:24.04:LTS: golang-github-ulikunitz-xz, Ubuntu:25.10: golang-github-ulikunitz-xz, Ubuntu:26.04:LTS: golang-github-ulikunitz-xz</p>
<p>xz is a pure golang package for reading and writing xz-compressed files. Prior to version 0.5.14, it is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the specification. Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. This issue has been patched in version 0.5.14.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-58058"/>
  </entry>
</feed>
