<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 20:40:21 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-09656</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-09656</link>
      <description>bdu:2026-09656</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-09656</guid>
    </item>
    <item>
      <title>EUVD-2026-309051</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-309051</link>
      <description>EUVD-2026-309051</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-309051</guid>
    </item>
    <item>
      <title>fkie_cve-2026-41648</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-41648</link>
      <description>&lt;p&gt;Incus is a system container and virtual machine manager. Prior to version 7.0.0, user provided image and backup tarballs would be unpacked and YAML files parsed without any size restrictions. This was making it easy for an authenticated user to provide a crafted image or backup tarball that when parsed by Incus would lead to a very large YAML document being loaded into memory, potentially causing the entire server to run out of memory. This issue has been patched in version 7.0.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Incus is a system container and virtual machine manager. Prior to version 7.0.0, user provided image and backup tarballs would be unpacked and YAML files parsed without any size restrictions. This was making it easy for an authenticated user to provide a crafted image or backup tarball that when parsed by Incus would lead to a very large YAML document being loaded into memory, potentially causing the entire server to run out of memory. This issue has been patched in version 7.0.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-41648</guid>
    </item>
    <item>
      <title>GHSA-67wx-r9xr-x75x — Incus has Unbounded YAML Metadata Decode via Parsing</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-67wx-r9xr-x75x</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/lxc/incus/v6/cmd/incusd&lt;/p&gt;
&lt;p&gt;### Summary
User provided image and backup tarballs would be unpacked and YAML files parsed without any size restrictions. This was making it easy for an authenticated user to provide a crafted image or backup tarball that when parsed by Incus would lead to a very large YAML document being loaded into memory, potentially causing the entire server to run out of memory.&lt;/p&gt;
&lt;p&gt;### Details
It was found that getImageMetadata and backup.GetInfo call yaml.NewDecoder(tr).Decode() directly on the tar reader without limiting how many bytes the YAML decoder can consume. The tar entry hdr.Size is not checked before decoding.&lt;/p&gt;
&lt;p&gt;A tar archive can be crafted in which metadata.yaml or backup/index.yaml declares a large size in the tar header, causing the YAML decoder to read and allocate proportional memory on the server. The gopkg.in/yaml.v2 library mitigates YAML alias and anchor bombs, such as “billion laughs,” through its built-in excessive-aliasing check. However, large flat YAML documents with many keys or long string values can still produce linear but amplified memory consumption of approximately 5x to 6x the input size.&lt;/p&gt;
&lt;p&gt;A 200 MB tar entry for metadata.yaml may cause approximately 1.2 GB of heap allocations during decode, which may be sufficient to trigger an out-of-memory condition on a constrained daemon or significantly degrade service. Because the decode occurs in the daemon process, excessive garbage-collection pressure can affect concurrent operations. Appropriate API permissions a…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/lxc/incus/v6/cmd/incusd&lt;/p&gt;
&lt;p&gt;### Summary
User provided image and backup tarballs would be unpacked and YAML files parsed without any size restrictions. This was making it easy for an authenticated user to provide a crafted image or backup tarball that when parsed by Incus would lead to a very large YAML document being loaded into memory, potentially causing the entire server to run out of memory.&lt;/p&gt;
&lt;p&gt;### Details
It was found that getImageMetadata and backup.GetInfo call yaml.NewDecoder(tr).Decode() directly on the tar reader without limiting how many bytes the YAML decoder can consume. The tar entry hdr.Size is not checked before decoding.&lt;/p&gt;
&lt;p&gt;A tar archive can be crafted in which metadata.yaml or backup/index.yaml declares a large size in the tar header, causing the YAML decoder to read and allocate proportional memory on the server. The gopkg.in/yaml.v2 library mitigates YAML alias and anchor bombs, such as “billion laughs,” through its built-in excessive-aliasing check. However, large flat YAML documents with many keys or long string values can still produce linear but amplified memory consumption of approximately 5x to 6x the input size.&lt;/p&gt;
&lt;p&gt;A 200 MB tar entry for metadata.yaml may cause approximately 1.2 GB of heap allocations during decode, which may be sufficient to trigger an out-of-memory condition on a constrained daemon or significantly degrade service. Because the decode occurs in the daemon process, excessive garbage-collection pressure can affect concurrent operations. Appropriate API permissions a…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-67wx-r9xr-x75x</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-41648</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-41648</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:16.04:LTS: lxd, Ubuntu:Pro:18.04:LTS: lxd, Ubuntu:20.04:LTS: lxd, Ubuntu:Pro:24.04:LTS: incus, Ubuntu:25.10: incus, Ubuntu:Pro:26.04:LTS: incus&lt;/p&gt;
&lt;p&gt;Incus is a system container and virtual machine manager. Prior to version 7.0.0, user provided image and backup tarballs would be unpacked and YAML files parsed without any size restrictions. This was making it easy for an authenticated user to provide a crafted image or backup tarball that when parsed by Incus would lead to a very large YAML document being loaded into memory, potentially causing the entire server to run out of memory. This issue has been patched in version 7.0.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:16.04:LTS: lxd, Ubuntu:Pro:18.04:LTS: lxd, Ubuntu:20.04:LTS: lxd, Ubuntu:Pro:24.04:LTS: incus, Ubuntu:25.10: incus, Ubuntu:Pro:26.04:LTS: incus&lt;/p&gt;
&lt;p&gt;Incus is a system container and virtual machine manager. Prior to version 7.0.0, user provided image and backup tarballs would be unpacked and YAML files parsed without any size restrictions. This was making it easy for an authenticated user to provide a crafted image or backup tarball that when parsed by Incus would lead to a very large YAML document being loaded into memory, potentially causing the entire server to run out of memory. This issue has been patched in version 7.0.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-41648</guid>
    </item>
  </channel>
</rss>
