<?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 11:00:05 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-53492</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-53492</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:25: containerd, Alpaquita:stream: containerd&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:25: containerd, Alpaquita:stream: containerd&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-53492</guid>
    </item>
    <item>
      <title>Withdrawn: CLEANSTART-2026-BS31967 — Security fixes in rancher-fleet-agent 0.13.13-r1</title>
      <link>https://cve.radiocsirt.org/vuln/cleanstart-2026-bs31967</link>
      <description>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: rancher-fleet-agent&lt;/p&gt;
&lt;p&gt;Package rancher-fleet-agent version 0.13.13-r1 fixes 34 vulnerabilities: CVE-2026-50195, CVE-2026-53492, CVE-2026-46680, CVE-2026-53488, CVE-2026-53489...&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: rancher-fleet-agent&lt;/p&gt;
&lt;p&gt;Package rancher-fleet-agent version 0.13.13-r1 fixes 34 vulnerabilities: CVE-2026-50195, CVE-2026-53492, CVE-2026-46680, CVE-2026-53488, CVE-2026-53489...&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cleanstart-2026-bs31967</guid>
    </item>
    <item>
      <title>EUVD-2026-332259</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-332259</link>
      <description>EUVD-2026-332259</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-332259</guid>
    </item>
    <item>
      <title>fkie_cve-2026-53492</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-53492</link>
      <description>&lt;p&gt;containerd is an open-source container runtime. In Versions prior to 2.3.2, 2.2.5 and 2.1.9, the CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. When restoring a container from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive rather than relying solely on the pod&amp;#39;s create-time specification. This allows a user with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement, injecting arbitrary CDI edits (such as device nodes and host mounts) into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are not affected. This issue has been fixed in versions 2.3.2, 2.2.5 and 2.1.9.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;containerd is an open-source container runtime. In Versions prior to 2.3.2, 2.2.5 and 2.1.9, the CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. When restoring a container from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive rather than relying solely on the pod&amp;#39;s create-time specification. This allows a user with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement, injecting arbitrary CDI edits (such as device nodes and host mounts) into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are not affected. This issue has been fixed in versions 2.3.2, 2.2.5 and 2.1.9.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-53492</guid>
    </item>
    <item>
      <title>GHSA-33vj-92qq-66hc — containerd CRI checkpoint restore CDI annotation smuggling</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-33vj-92qq-66hc</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/containerd/containerd/v2&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;containerd&amp;#39;s CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. When restoring a container from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive rather than relying solely on the pod&amp;#39;s create-time specification. This allows a user with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement, injecting arbitrary CDI edits (such as device nodes and host mounts) into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are not affected.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This bug has been fixed in the following containerd versions:&lt;/p&gt;
&lt;p&gt;* 2.3.2
* 2.2.5
* 2.1.9&lt;/p&gt;
&lt;p&gt;Users should update to these versions to resolve the issue. Recreating existing containers restored from untrusted checkpoints may be necessary to remove smuggled configuration.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Users can mitigate this issue by restricting the restoration of containers from untrusted checkpoint images. If Container Device Interface (CDI) capabilities are not utilized on the node, removing or temporarily relocating host CDI specifications from the default directories (`/etc/cdi` and `/var/run/cdi`) will eliminate the reachability of this vulnerability.&lt;/p&gt;
&lt;p&gt;### C…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/containerd/containerd/v2&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;containerd&amp;#39;s CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. When restoring a container from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive rather than relying solely on the pod&amp;#39;s create-time specification. This allows a user with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement, injecting arbitrary CDI edits (such as device nodes and host mounts) into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are not affected.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This bug has been fixed in the following containerd versions:&lt;/p&gt;
&lt;p&gt;* 2.3.2
* 2.2.5
* 2.1.9&lt;/p&gt;
&lt;p&gt;Users should update to these versions to resolve the issue. Recreating existing containers restored from untrusted checkpoints may be necessary to remove smuggled configuration.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Users can mitigate this issue by restricting the restoration of containers from untrusted checkpoint images. If Container Device Interface (CDI) capabilities are not utilized on the node, removing or temporarily relocating host CDI specifications from the default directories (`/etc/cdi` and `/var/run/cdi`) will eliminate the reachability of this vulnerability.&lt;/p&gt;
&lt;p&gt;### C…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-33vj-92qq-66hc</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11102-1 — trivy-0.71.2-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11102-1</link>
      <description>&lt;p&gt;trivy-0.71.2-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;trivy-0.71.2-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11102-1</guid>
    </item>
    <item>
      <title>RHSA-2026:15862 — Red Hat Security Advisory: Red Hat Hardened Images RPMs bug fix and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2026:15862</link>
      <description>&lt;p&gt;github.com/quic-go/quic-go: quic-go: Denial of Service via excessive memory allocation in HTTP/3 trailers urllib3: urllib3: Denial of Service due to excessive HTTP response decompression go.opentelemetry.io/otel: go.opentelemetry.io/otel/schema/v1.0: go.opentelemetry.io/otel/schema/v1.1: OpenTelemetry-Go: Denial of Service due to file descriptor leak github.com/containerd/containerd: containerd: Arbitrary host file read via symlink following in CRI checkpoint restore github.com/containerd/containerd: containerd: Security bypass via Container Device Interface (CDI) annotation smuggling during checkpoint restoration.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;github.com/quic-go/quic-go: quic-go: Denial of Service via excessive memory allocation in HTTP/3 trailers urllib3: urllib3: Denial of Service due to excessive HTTP response decompression go.opentelemetry.io/otel: go.opentelemetry.io/otel/schema/v1.0: go.opentelemetry.io/otel/schema/v1.1: OpenTelemetry-Go: Denial of Service due to file descriptor leak github.com/containerd/containerd: containerd: Arbitrary host file read via symlink following in CRI checkpoint restore github.com/containerd/containerd: containerd: Security bypass via Container Device Interface (CDI) annotation smuggling during checkpoint restoration.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2026:15862</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-53492</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-53492</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:22.04:LTS: containerd-app, Ubuntu:24.04:LTS: containerd-app, Ubuntu:25.10: containerd-app, Ubuntu:25.10: containerd-stable, Ubuntu:26.04:LTS: containerd-app, Ubuntu:26.04:LTS: containerd-stable&lt;/p&gt;
&lt;p&gt;containerd is an open-source container runtime. In Versions prior to 2.3.2, 2.2.5 and 2.1.9, the CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. When restoring a container from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive rather than relying solely on the pod&amp;#39;s create-time specification. This allows a user with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement, injecting arbitrary CDI edits (such as device nodes and host mounts) into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are not affected. This issue has been fixed in versions 2.3.2, 2.2.5 and 2.1.9.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:22.04:LTS: containerd-app, Ubuntu:24.04:LTS: containerd-app, Ubuntu:25.10: containerd-app, Ubuntu:25.10: containerd-stable, Ubuntu:26.04:LTS: containerd-app, Ubuntu:26.04:LTS: containerd-stable&lt;/p&gt;
&lt;p&gt;containerd is an open-source container runtime. In Versions prior to 2.3.2, 2.2.5 and 2.1.9, the CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. When restoring a container from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive rather than relying solely on the pod&amp;#39;s create-time specification. This allows a user with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement, injecting arbitrary CDI edits (such as device nodes and host mounts) into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are not affected. This issue has been fixed in versions 2.3.2, 2.2.5 and 2.1.9.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-53492</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2009 — Google Cloud Platform (GKE containerd): Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2009</link>
      <description>&lt;p&gt;Ein entfernter, authentisierter Angreifer kann mehrere Schwachstellen in Google Cloud Platform ausnutzen, um beliebigen Programmcode auszuführen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren, vertrauliche Informationen offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, authentisierter Angreifer kann mehrere Schwachstellen in Google Cloud Platform ausnutzen, um beliebigen Programmcode auszuführen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren, vertrauliche Informationen offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2009</guid>
    </item>
  </channel>
</rss>
