<?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>Fri, 09 Oct 2026 05:47:59 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-35469 — SpdyStream: DOS on CRI</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2026-35469</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; moby spdystream, Red Hat OpenShift Container Platform 4.19, Red Hat RHEM 1.0 for RHEL 9, Red Hat RHEM 1.1 for RHEL 10, Red Hat RHEM 1.1 for RHEL 9, Red Hat Cluster Observability Operator 1.5.0, Red Hat Logging Subsystem for Red Hat OpenShift 6.6, Red Hat multicluster engine for Kubernetes 2.1, Red Hat multicluster engine for Kubernetes 2.11, Red Hat multicluster engine for Kubernetes 2.8 and 37 more&lt;/p&gt;
&lt;p&gt;spdystream is a Go library for multiplexing streams over SPDY connections. In versions 0.5.0 and below, the SPDY/3 frame parser does not validate attacker-controlled counts and lengths before allocating memory. Three allocation paths are affected: the SETTINGS frame entry count, the header count in parseHeaderValueBlock, and individual header field sizes — all read as 32-bit integers and used directly as allocation sizes with no bounds checking. Because SPDY header blocks are zlib-compressed, a small on-the-wire payload can decompress into large attacker-controlled values. A remote peer that can send SPDY frames to a service using spdystream can exhaust process memory and cause an out-of-memory crash with a single crafted control frame. This issue has been fixed in version 0.5.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; moby spdystream, Red Hat OpenShift Container Platform 4.19, Red Hat RHEM 1.0 for RHEL 9, Red Hat RHEM 1.1 for RHEL 10, Red Hat RHEM 1.1 for RHEL 9, Red Hat Cluster Observability Operator 1.5.0, Red Hat Logging Subsystem for Red Hat OpenShift 6.6, Red Hat multicluster engine for Kubernetes 2.1, Red Hat multicluster engine for Kubernetes 2.11, Red Hat multicluster engine for Kubernetes 2.8 and 37 more&lt;/p&gt;
&lt;p&gt;spdystream is a Go library for multiplexing streams over SPDY connections. In versions 0.5.0 and below, the SPDY/3 frame parser does not validate attacker-controlled counts and lengths before allocating memory. Three allocation paths are affected: the SETTINGS frame entry count, the header count in parseHeaderValueBlock, and individual header field sizes — all read as 32-bit integers and used directly as allocation sizes with no bounds checking. Because SPDY header blocks are zlib-compressed, a small on-the-wire payload can decompress into large attacker-controlled values. A remote peer that can send SPDY frames to a service using spdystream can exhaust process memory and cause an out-of-memory crash with a single crafted control frame. This issue has been fixed in version 0.5.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2026-35469</guid>
    </item>
    <item>
      <title>GHSA-hr2v-4r36-88hr — Helm Chart extraction output directory collapse via `Chart.yaml` name dot-segment</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-hr2v-4r36-88hr</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: helm.sh/helm/v4, Go: helm.sh/helm/v3&lt;/p&gt;
&lt;p&gt;Helm is a package manager for Charts for Kubernetes. In Helm versions &amp;lt;=3.20.1 and &amp;lt;=4.1.3, a specially crafted Chart will cause `helm pull --untar  [chart URL | repo/chartname]` to write the Chart&amp;#39;s contents to the immediate output directory (as defaulted to the current working directory; or as given by the `--destination` and `--untardir` flags), rather than the expected output directory suffixed by the chart&amp;#39;s name.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;The bug enables writing the Chart&amp;#39;s contents (unpackaged/untar&amp;#39;ed) to the output directory `&amp;lt;output dir&amp;gt;/`, instead of the expected `&amp;lt;output dir&amp;gt;/&amp;lt;chart name&amp;gt;/`, potentially overwriting the contents of the targeted directory.&lt;/p&gt;
&lt;p&gt;Note: a chart name containing POSIX dot-dot, or dot-dot and slashes (as if to refer to parent directories) do not resolve beyond the output directory as designed.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This issue has been resolved in Helm v3.20.2 and v4.1.3&lt;/p&gt;
&lt;p&gt;A Chart with an unexpected name (those specified to be &amp;#34;.&amp;#34; or &amp;#34;..&amp;#34;), or a Chart name which results in a non-unique directory will be rejected.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Ensure the the name of the Chart does not comprise/contain POSIX pathname special directory references ie. dot-dot (&amp;#34;..&amp;#34;) or dot (&amp;#34;.&amp;#34;). In addition, ensuring that the `pull --untar` flag (or equivalent SDK option) refers to a unique/empty output directory prevents chart extraction from inadvertently overwriting existing files within the specified directory.&lt;/p&gt;
&lt;p&gt;### Credits&lt;/p&gt;
&lt;p&gt;Oleh Konko
@1seal&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: helm.sh/helm/v4, Go: helm.sh/helm/v3&lt;/p&gt;
&lt;p&gt;Helm is a package manager for Charts for Kubernetes. In Helm versions &amp;lt;=3.20.1 and &amp;lt;=4.1.3, a specially crafted Chart will cause `helm pull --untar  [chart URL | repo/chartname]` to write the Chart&amp;#39;s contents to the immediate output directory (as defaulted to the current working directory; or as given by the `--destination` and `--untardir` flags), rather than the expected output directory suffixed by the chart&amp;#39;s name.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;The bug enables writing the Chart&amp;#39;s contents (unpackaged/untar&amp;#39;ed) to the output directory `&amp;lt;output dir&amp;gt;/`, instead of the expected `&amp;lt;output dir&amp;gt;/&amp;lt;chart name&amp;gt;/`, potentially overwriting the contents of the targeted directory.&lt;/p&gt;
&lt;p&gt;Note: a chart name containing POSIX dot-dot, or dot-dot and slashes (as if to refer to parent directories) do not resolve beyond the output directory as designed.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This issue has been resolved in Helm v3.20.2 and v4.1.3&lt;/p&gt;
&lt;p&gt;A Chart with an unexpected name (those specified to be &amp;#34;.&amp;#34; or &amp;#34;..&amp;#34;), or a Chart name which results in a non-unique directory will be rejected.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Ensure the the name of the Chart does not comprise/contain POSIX pathname special directory references ie. dot-dot (&amp;#34;..&amp;#34;) or dot (&amp;#34;.&amp;#34;). In addition, ensuring that the `pull --untar` flag (or equivalent SDK option) refers to a unique/empty output directory prevents chart extraction from inadvertently overwriting existing files within the specified directory.&lt;/p&gt;
&lt;p&gt;### Credits&lt;/p&gt;
&lt;p&gt;Oleh Konko
@1seal&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-hr2v-4r36-88hr</guid>
    </item>
  </channel>
</rss>
