<?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://db.gcve.eu</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 11:37:12 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-41685 — Incus: Unbounded binary import disk exhaustion</title>
      <link>https://db.gcve.eu/vuln/cve-2026-41685</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; lxc incus&lt;/p&gt;
&lt;p&gt;Incus is a system container and virtual machine manager. Prior to version 7.0.0, uploads of large amount of data by authenticated users can run the Incus server out of disk space, potentially taking down the host system. The impact here is limited for anyone using storage.images_volume and storage.backups_volume as those users will have large uploads be stored on those volumes rather than directly on the host filesystem. This is the default behavior on IncusOS. 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; lxc incus&lt;/p&gt;
&lt;p&gt;Incus is a system container and virtual machine manager. Prior to version 7.0.0, uploads of large amount of data by authenticated users can run the Incus server out of disk space, potentially taking down the host system. The impact here is limited for anyone using storage.images_volume and storage.backups_volume as those users will have large uploads be stored on those volumes rather than directly on the host filesystem. This is the default behavior on IncusOS. This issue has been patched in version 7.0.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-41685</guid>
    </item>
    <item>
      <title>GHSA-98vh-x9cx-9cfp — Incus is affected by unbounded binary import disk exhaustion</title>
      <link>https://db.gcve.eu/vuln/ghsa-98vh-x9cx-9cfp</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
Uploads of large amount of data by authenticated users can run the Incus server out of disk space, potentially taking down the host system.&lt;/p&gt;
&lt;p&gt;The impact here is limited for anyone using `storage.images_volume` and `storage.backups_volume` as those users will have large uploads be stored on those volumes rather than directly on the host filesystem. This is the default behavior on IncusOS.&lt;/p&gt;
&lt;p&gt;### Details
Multiple binary import paths accept application/octet-stream requests and stream the HTTP request body directly into temporary files on the host without any visible request-size limit on the upload path.&lt;/p&gt;
&lt;p&gt;When these endpoints receive binary content, the daemon routes the request body into import routines that create temporary files under daemon-controlled host storage locations and copy the full attacker-controlled stream into them using direct io.Copy operations. This write occurs before the uploaded content is fully parsed and before later validation can reject the import.&lt;/p&gt;
&lt;p&gt;Because no visible http.MaxBytesReader, io.LimitReader, quota-aware wrapper, or equivalent size-enforcement mechanism is present around these upload paths, an authenticated attacker can supply an arbitrarily large continuous stream of data. This causes the daemon to keep writing unbounded input to host storage until the operation fails or the underlying file system is exhausted. In a multi-tenant deployment, this can be used to consume shared disk space and cause denial of service on the node.&lt;/p&gt;
&lt;p&gt;T…&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
Uploads of large amount of data by authenticated users can run the Incus server out of disk space, potentially taking down the host system.&lt;/p&gt;
&lt;p&gt;The impact here is limited for anyone using `storage.images_volume` and `storage.backups_volume` as those users will have large uploads be stored on those volumes rather than directly on the host filesystem. This is the default behavior on IncusOS.&lt;/p&gt;
&lt;p&gt;### Details
Multiple binary import paths accept application/octet-stream requests and stream the HTTP request body directly into temporary files on the host without any visible request-size limit on the upload path.&lt;/p&gt;
&lt;p&gt;When these endpoints receive binary content, the daemon routes the request body into import routines that create temporary files under daemon-controlled host storage locations and copy the full attacker-controlled stream into them using direct io.Copy operations. This write occurs before the uploaded content is fully parsed and before later validation can reject the import.&lt;/p&gt;
&lt;p&gt;Because no visible http.MaxBytesReader, io.LimitReader, quota-aware wrapper, or equivalent size-enforcement mechanism is present around these upload paths, an authenticated attacker can supply an arbitrarily large continuous stream of data. This causes the daemon to keep writing unbounded input to host storage until the operation fails or the underlying file system is exhausted. In a multi-tenant deployment, this can be used to consume shared disk space and cause denial of service on the node.&lt;/p&gt;
&lt;p&gt;T…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-98vh-x9cx-9cfp</guid>
    </item>
  </channel>
</rss>
