<?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-12T13:07:10.536345+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-25621</id>
    <title>CVE-2024-25621 — containerd affected by a local privilege escalation via wide permissions on CRI directory</title>
    <updated>2026-10-12T13:07:10.655351+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> containerd</p>
<p>containerd is an open-source container runtime. Versions 0.1.0 through 1.7.28, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4 and 2.2.0-beta.0 through 2.2.0-rc.1 have an overly broad default permission vulnerability. Directory paths `/var/lib/containerd`, `/run/containerd/io.containerd.grpc.v1.cri` and `/run/containerd/io.containerd.sandbox.controller.v1.shim` were all created with incorrect permissions. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. Workarounds include updating system administrator permissions so the host can manually chmod the directories to not have group or world accessible permissions, or to run containerd in rootless mode.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2024-25621"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-9h84-qmv7-982p</id>
    <title>GHSA-9h84-qmv7-982p — Helm Charts with Specific JSON Schema Values Can Cause Memory Exhaustion</title>
    <updated>2026-10-12T13:07:10.655408+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: helm.sh/helm/v3</p>
<p>A Helm contributor discovered that it was possible to craft a JSON Schema file in a manner which could cause Helm to use all available memory and have an out of memory (OOM) termination.</p>
<p>### Impact
A malicious chart can point `$ref` in _values.schema.json_ to a device (e.g. `/dev/*`) or other problem file which could cause Helm to use all available memory and have an out of memory (OOM) termination.</p>
<p>### Patches
This issue has been resolved in Helm v3.18.5.</p>
<p>### Workarounds
Make sure that all Helm charts that are being loaded into Helm doesn't have any reference of `$ref` pointing to `/dev/zero`.</p>
<p>### References
Helm's security policy is spelled out in detail in our [SECURITY](https://github.com/helm/community/blob/master/SECURITY.md) document.</p>
<p>### Credits
Disclosed by Jakub Ciolek at AlphaSense.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-9h84-qmv7-982p"/>
  </entry>
</feed>
