<?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 21:17:17 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-15558 — Docker Desktop Docker Plugins Uncontrolled Search Path Element Local Privilege Escalation Vulnerability</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-15558</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Docker CLI, Docker Compose, Red Hat Assisted Installer for Red Hat OpenShift Container Platform 2, Red Hat Builds for Red Hat OpenShift, Red Hat Gatekeeper 3, Red Hat Kernel Module Management Operator for Red Hat Openshift, Red Hat Machine Deletion Remediation Operator, Red Hat Multicluster Engine for Kubernetes, Red Hat Multicluster Global Hub, Red Hat OpenShift Pipelines and 19 more&lt;/p&gt;
&lt;p&gt;Docker CLI for Windows searches for plugin binaries in C:\ProgramData\Docker\cli-plugins, a directory that does not exist by default. A low-privileged attacker can create this directory and place malicious CLI plugin binaries (docker-compose.exe, docker-buildx.exe, etc.) that are executed when a victim user opens Docker Desktop or invokes Docker CLI plugin features, and allow privilege-escalation if the docker CLI is executed as a privileged user.&lt;/p&gt;
&lt;p&gt;This issue affects Docker CLI: through 29.1.5 and Windows binaries acting as a CLI-plugin manager using the  github.com/docker/cli/cli-plugins/manager https://pkg.go.dev/github.com/docker/cli@v29.1.5+incompatible/cli-plugins/manager  package, such as Docker Compose.&lt;/p&gt;
&lt;p&gt;This issue does not impact non-Windows binaries, and projects not using the plugin-manager code.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Docker CLI, Docker Compose, Red Hat Assisted Installer for Red Hat OpenShift Container Platform 2, Red Hat Builds for Red Hat OpenShift, Red Hat Gatekeeper 3, Red Hat Kernel Module Management Operator for Red Hat Openshift, Red Hat Machine Deletion Remediation Operator, Red Hat Multicluster Engine for Kubernetes, Red Hat Multicluster Global Hub, Red Hat OpenShift Pipelines and 19 more&lt;/p&gt;
&lt;p&gt;Docker CLI for Windows searches for plugin binaries in C:\ProgramData\Docker\cli-plugins, a directory that does not exist by default. A low-privileged attacker can create this directory and place malicious CLI plugin binaries (docker-compose.exe, docker-buildx.exe, etc.) that are executed when a victim user opens Docker Desktop or invokes Docker CLI plugin features, and allow privilege-escalation if the docker CLI is executed as a privileged user.&lt;/p&gt;
&lt;p&gt;This issue affects Docker CLI: through 29.1.5 and Windows binaries acting as a CLI-plugin manager using the  github.com/docker/cli/cli-plugins/manager https://pkg.go.dev/github.com/docker/cli@v29.1.5+incompatible/cli-plugins/manager  package, such as Docker Compose.&lt;/p&gt;
&lt;p&gt;This issue does not impact non-Windows binaries, and projects not using the plugin-manager code.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-15558</guid>
    </item>
    <item>
      <title>GHSA-557j-xg8c-q2mm — Helm vulnerable to Code Injection through malicious chart.yaml content</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-557j-xg8c-q2mm</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: helm.sh/helm/v3&lt;/p&gt;
&lt;p&gt;A Helm contributor discovered that a specially crafted `Chart.yaml` file along with a specially linked `Chart.lock` file can lead to local code execution when dependencies are updated.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Fields in a `Chart.yaml` file, that are carried over to a `Chart.lock` file when dependencies are updated and this file is written, can be crafted in a way that can cause execution if that same content were in a file that is executed (e.g., a `bash.rc` file or shell script). If the `Chart.lock` file is symlinked to one of these files updating dependencies will write the lock file content to the symlinked file. This can lead to unwanted execution. Helm warns of the symlinked file but did not stop execution due to symlinking.&lt;/p&gt;
&lt;p&gt;This affects when dependencies are updated. When using the `helm` command this happens when `helm dependency update` is run. `helm dependency build` can write a lock file when one does not exist but this vector requires one to already exist. This affects the Helm SDK when the downloader `Manager` performs an update.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This issue has been resolved in Helm v3.18.4&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Ensure the `Chart.lock` file in a chart is not a symlink prior to updating dependencies.&lt;/p&gt;
&lt;p&gt;### For more information&lt;/p&gt;
&lt;p&gt;Helm&amp;#39;s security policy is spelled out in detail in our [SECURITY](https://github.com/helm/community/blob/master/SECURITY.md) document.&lt;/p&gt;
&lt;p&gt;### Credits&lt;/p&gt;
&lt;p&gt;Disclosed by Jakub Ciolek at AlphaSense.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: helm.sh/helm/v3&lt;/p&gt;
&lt;p&gt;A Helm contributor discovered that a specially crafted `Chart.yaml` file along with a specially linked `Chart.lock` file can lead to local code execution when dependencies are updated.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Fields in a `Chart.yaml` file, that are carried over to a `Chart.lock` file when dependencies are updated and this file is written, can be crafted in a way that can cause execution if that same content were in a file that is executed (e.g., a `bash.rc` file or shell script). If the `Chart.lock` file is symlinked to one of these files updating dependencies will write the lock file content to the symlinked file. This can lead to unwanted execution. Helm warns of the symlinked file but did not stop execution due to symlinking.&lt;/p&gt;
&lt;p&gt;This affects when dependencies are updated. When using the `helm` command this happens when `helm dependency update` is run. `helm dependency build` can write a lock file when one does not exist but this vector requires one to already exist. This affects the Helm SDK when the downloader `Manager` performs an update.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This issue has been resolved in Helm v3.18.4&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Ensure the `Chart.lock` file in a chart is not a symlink prior to updating dependencies.&lt;/p&gt;
&lt;p&gt;### For more information&lt;/p&gt;
&lt;p&gt;Helm&amp;#39;s security policy is spelled out in detail in our [SECURITY](https://github.com/helm/community/blob/master/SECURITY.md) document.&lt;/p&gt;
&lt;p&gt;### Credits&lt;/p&gt;
&lt;p&gt;Disclosed by Jakub Ciolek at AlphaSense.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-557j-xg8c-q2mm</guid>
    </item>
  </channel>
</rss>
