<?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-05T02:26:14.689097+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/cve-2024-8676</id>
    <title>CVE-2024-8676 — Cri-o: checkpoint restore can be triggered from different namespaces</title>
    <updated>2026-10-05T02:26:14.690928+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> cri-o, Red Hat OpenShift Container Platform 4.15, Red Hat OpenShift Container Platform 4.16, Red Hat OpenShift Container Platform 4.17, Red Hat OpenShift Container Platform 4.18, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 9, Red Hat OpenShift Container Platform 3.11, Red Hat OpenShift Container Platform 4</p>
<p>A vulnerability was found in CRI-O, where it can be requested to take a checkpoint archive of a container and later be asked to restore it. When it does that restoration, it attempts to restore the mounts from the restore archive instead of the pod request. As a result, the validations run on the pod spec, verifying that the pod has access to the mounts it specifies are not applicable to a restored container. This flaw allows a malicious user to trick CRI-O into restoring a pod that doesn't have access to host mounts. The user needs access to the kubelet or cri-o socket to call the restore endpoint and trigger the restore.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2024-8676"/>
  </entry>
</feed>
