<?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-07T17:58:06.837330+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-2020-8911</id>
    <title>CVE-2020-8911 — CBC padding oracle in AWS S3 Crypto SDK for GoLang</title>
    <updated>2026-10-07T17:58:07.012059+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Google LLC AWS S3 Crypto SDK for GoLang</p>
<p>A padding oracle vulnerability exists in the AWS S3 Crypto SDK for GoLang versions prior to V2. The SDK allows users to encrypt files with AES-CBC without computing a Message Authentication Code (MAC), which then allows an attacker who has write access to the target's S3 bucket and can observe whether or not an endpoint with access to the key can decrypt a file, they can reconstruct the plaintext with (on average) 128*length (plaintext) queries to the endpoint, by exploiting CBC's ability to manipulate the bytes of the next block and PKCS5 padding errors. It is recommended to update your SDK to V2 or later, and re-encrypt your files.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2020-8911"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-hr2v-4r36-88hr</id>
    <title>GHSA-hr2v-4r36-88hr — Helm Chart extraction output directory collapse via `Chart.yaml` name dot-segment</title>
    <updated>2026-10-07T17:58:07.012136+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: helm.sh/helm/v4, Go: helm.sh/helm/v3</p>
<p>Helm is a package manager for Charts for Kubernetes. In Helm versions &lt;=3.20.1 and &lt;=4.1.3, a specially crafted Chart will cause `helm pull --untar  [chart URL | repo/chartname]` to write the Chart'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's name.</p>
<p>### Impact</p>
<p>The bug enables writing the Chart's contents (unpackaged/untar'ed) to the output directory `&lt;output dir&gt;/`, instead of the expected `&lt;output dir&gt;/&lt;chart name&gt;/`, potentially overwriting the contents of the targeted directory.</p>
<p>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.</p>
<p>### Patches</p>
<p>This issue has been resolved in Helm v3.20.2 and v4.1.3</p>
<p>A Chart with an unexpected name (those specified to be "." or ".."), or a Chart name which results in a non-unique directory will be rejected.</p>
<p>### Workarounds</p>
<p>Ensure the the name of the Chart does not comprise/contain POSIX pathname special directory references ie. dot-dot ("..") or dot ("."). 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.</p>
<p>### Credits</p>
<p>Oleh Konko
@1seal</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-hr2v-4r36-88hr"/>
  </entry>
</feed>
