Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
22 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Helm is a package manager for Charts for Kubernetes. In Helm versions <=3.20.1 and <=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. Impact The bug enables writing the Chart's contents (unpackaged/untar'ed) to the output directory <output dir/, instead of the expected <output dir/<chart name/, potentially overwriting the contents of the targeted directory. 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. Patches This issue has been resolved in Helm v3.20.2 and v4.1.3 A Chart with an unexpected name (those specified to be "." or ".."), or a Chart name which results in a non-unique directory will…
Recommended action: Upgrade to 3.20.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Helm contributor discovered an improper validation of type error when parsing Chart.yaml and index.yaml files that can lead to a panic. Impact There are two areas of YAML validation that were impacted. First, when a Chart.yaml file had a null maintainer or the child or parent of a dependencies import-values could be parsed as something other than a string, helm lint would panic. Second, when an index.yaml had an empty entry in the list of chart versions Helm would panic on interactions with that repository. Patches This issue has been resolved in Helm v3.18.5. Workarounds Ensure YAML files are formatted as Helm expects prior to processing them with Helm. References Helm's security policy is spelled out in detail in our SECURITY document. Credits Disclosed by Jakub Ciolek at AlphaSense.
Recommended action: Upgrade to 3.18.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. 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. Patches This issue has been resolved in Helm v3.18.5. Workarounds Make sure that all Helm charts that are being loaded into Helm doesn't have any reference of $ref pointing to /dev/zero. References Helm's security policy is spelled out in detail in our SECURITY document. Credits Disclosed by Jakub Ciolek at AlphaSense.
Recommended action: Upgrade to 3.18.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go helm.sh/helm/v3 >= 3.18.0-rc.1, < 3.18.4; < 3.17.4
Fixed in
3.18.43.17.4· Vendor fix available
Issue
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. Impact 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. 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…
Recommended action: Upgrade to 3.18.4 or 3.17.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Helm contributor discovered that a specially crafted JSON Schema within a chart can lead to a stack overflow. Impact A JSON Schema file within a chart can be crafted with a deeply nested chain of references, leading to parser recursion that can exceed the stack size limit and trigger a stack overflow. Patches This issue has been resolved in Helm v3.17.3. Workarounds Ensure that the JSON Schema within any charts loaded by Helm does not have a large number of nested references. These JSON Schema files are larger than 10 MiB. For more information Helm's security policy is spelled out in detail in our SECURITY document. Credits Disclosed by Jakub Ciolek at AlphaSense.
Recommended action: Upgrade to 3.17.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Helm contributor discovered that a specially crafted chart archive file can cause Helm to use all available memory and have an out of memory (OOM) termination. Impact A chart archive file can be crafted in a manner where it expands to be significantly larger uncompressed than compressed (e.g., 800x difference). When Helm loads this specially crafted chart, memory can be exhausted causing the application to terminate. Patches This issue has been resolved in Helm v3.17.3. Workarounds Ensure that any chart archive files being loaded by Helm do not contain files that are large enough to cause the Helm Client or SDK to use up available memory leading to a termination. For more information Helm's security policy is spelled out in detail in our SECURITY document. Credits Disclosed by Jakub Ciolek at AlphaSense.
Recommended action: Upgrade to 3.17.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Helm contributor discovered uninitialized variable vulnerability when Helm parses index and plugin yaml files missing expected content. Impact When either an index.yaml file or a plugins plugin.yaml file were missing all metadata a panic would occur in Helm. In the Helm SDK this is found when using the LoadIndexFile or DownloadIndexFile functions in the repo package or the LoadDir function in the plugin package. For the Helm client this impacts functions around adding a repository and all Helm functions if a malicious plugin is added as Helm inspects all known plugins on each invocation. Patches This issue has been resolved in Helm v3.14.2. Workarounds If a malicious plugin has been added which is causing all Helm client commands to panic, the malicious plugin can be manually removed from the filesystem. If using Helm SDK versions prior to 3.14.2, calls to affected functions can use recover to catch the panic. For more information Helm's security policy is spelled out in detail in…
Recommended action: Upgrade to 3.14.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Helm contributor discovered a path traversal vulnerability when Helm saves a chart including at download time. Impact When either the Helm client or SDK is used to save a chart whose name within the Chart.yaml file includes a relative path change, the chart would be saved outside its expected directory based on the changes in the relative path. The validation and linting did not detect the path changes in the name. Patches This issue has been resolved in Helm v3.14.1. Workarounds Check all charts used by Helm for path changes in their name as found in the Chart.yaml file. This includes dependencies. Credits Disclosed by Dominykas Blyžė at Nearform Ltd.
Recommended action: Upgrade to 3.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Helm contributor discovered an information disclosure vulnerability using the getHostByName template function. Impact getHostByName is a Helm template function introduced in Helm v3. The function is able to accept a hostname and return an IP address for that hostname. To get the IP address the function performs a DNS lookup. The DNS lookup happens when used with helm install|upgrade|template or when the Helm SDK is used to render a chart. Information passed into the chart can be disclosed to the DNS servers used to lookup the IP address. For example, a malicious chart could inject getHostByName into a chart in order to disclose values to a malicious DNS server. Patches The issue has been fixed in Helm 3.11.1. Workarounds Prior to using a chart with Helm verify the getHostByName function is not being used in a template to disclose any information you do not want passed to DNS servers. For more information Helm's security policy is spelled out in detail in our SECURITY document.…
Recommended action: Upgrade to 3.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fuzz testing, by Ada Logics and sponsored by the CNCF, identified input to functions in the chartutil package that can cause a segmentation violation. Applications that use functions from the chartutil package in the Helm SDK can have a Denial of Service attack when they use this package and it panics. Impact The chartutil package contains a parser that loads a JSON Schema validation file. For example, the Helm client when rendering a chart will validate its values with the schema file. The chartutil package parses the schema file and loads it into structures Go can work with. Some schema files can cause array data structures to be created causing a memory violation. Applications that use the chartutil package in the Helm SDK to parse a schema file can suffer a Denial of Service when that input causes a panic that cannot be recovered from. The Helm Client will panic with a schema file that causes a memory violation panic. Helm is not a long running service so the panic will not…
Recommended action: Upgrade to 3.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fuzz testing, by Ada Logics and sponsored by the CNCF, identified input to functions in the repo package that can cause a segmentation violation. Applications that use functions from the repo package in the Helm SDK can have a Denial of Service attack when they use this package and it panics. Impact The repo package contains a handler that processes the index file of a repository. For example, the Helm client adds references to chart repositories where charts are managed. The repo package parses the index file of the repository and loads it into structures Go can work with. Some index files can cause array data structures to be created causing a memory violation. Applications that use the repo package in the Helm SDK to parse an index file can suffer a Denial of Service when that input causes a panic that cannot be recovered from. The Helm Client will panic with an index file that causes a memory violation panic. Helm is not a long running service so the panic will not affect future…
Recommended action: Upgrade to 3.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fuzz testing, by Ada Logics and sponsored by the CNCF, identified input to functions in the strvals package that can cause a stack overflow. In Go, a stack overflow cannot be recovered from. Applications that use functions from the strvals package in the Helm SDK can have a Denial of Service attack when they use this package and it panics. Impact The strvals package contains a parser that turns strings into Go structures. For example, the Helm client has command line flags like --set, --set-string, and others that enable the user to pass in strings that are merged into the values. The strvals package converts these strings into structures Go can work with. Some string inputs can cause array data structures to be created causing a stack overflow. Applications that use the strvals package in the Helm SDK to parse user supplied input can suffer a Denial of Service when that input causes a panic that cannot be recovered from. The Helm Client will panic with input to --set, --set-string,…
Recommended action: Upgrade to 3.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fuzz testing, by Ada Logics and sponsored by the CNCF, identified input to functions in the strvals package that can cause an out of memory panic. Out of memory panics cannot be recovered from. Applications that use functions from the strvals package in the Helm SDK can have a Denial of Service attack when they use this package and it panics. Impact The strvals package contains a parser that turns strings into Go structures. For example, the Helm client has command line flags like --set, --set-string, and others that enable the user to pass in strings that are merged into the values. The strvals package converts these strings into structures Go can work with. Some string inputs can cause array data structures to be created causing an out of memory panic. Applications that use the strvals package in the Helm SDK to parse user supplied input can suffer a Denial of Service when that input causes a panic that cannot be recovered from. The Helm Client will panic with input to --set,…
Recommended action: Upgrade to 3.9.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Since Helm 2 was released, a well-documented aspect of Helm is that the Helm chart's version number MUST follow the SemVer2 specification. In the past, Helm would not permit charts with malformed versions. At some point, a patch was merged that changed this - On a version parse error, the version number was simply passed along as-is. This provided a vector for malicious data to be injected into Helm and potentially used in various ways. Core maintainers were able to send deceptive information to a terminal screen running the helm command, as well as obscure or alter information on the screen. In some cases, we could send codes that terminals used to execute higher-order logic, like clearing a terminal screen. Further, during evaluation, the Helm maintainers discovered a few other fields that were not properly sanitized when read out of repository index files. This fix remedies all such cases, and once again enforces SemVer2 policies on version fields. All users of the Helm 3 should…
Recommended action: Upgrade to 3.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Helm core maintainers have identified an information disclosure vulnerability in Helm 3.0.0-3.2.3. Impact A traversal attack is possible when installing Helm plugins from a tar archive over HTTP. It is possible for a malicious plugin author to inject a relative path into a plugin archive, and copy a file outside of the intended directory. Traversal Attacks are a form of a Directory Traversal that can be exploited by extracting files from an archive. The premise of the Directory Traversal vulnerability is that an attacker can gain access to parts of the file system outside of the target folder in which they should reside. The attacker can then overwrite executable files and either invoke them remotely or wait for the system or user to call them, thus achieving Remote Command Execution on the victim's machine. The vulnerability can also cause damage by overwriting configuration files or other sensitive resources, and can be exploited on both client (user) machines and servers.…
Recommended action: Upgrade to 3.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
While working on the Helm source, a Helm core maintainer discovered a situation where the username and password credentials associated with a Helm repository could be passed on to another domain referenced by that Helm repository. Impact The index.yaml within a Helm chart repository contains a reference where to get the chart archive for each version of a chart. The reference can be relative to the index.yaml file or a URL to location. The URL can point to any domain and this is a feature leveraged by Helm users. For example, an index.yaml file can be hosted on GitHub pages while the chart archives are hosted as GitHub releases. These are on different domain names and the index.yaml file points to the other domain. When a username and password were associated with a Helm repository the username and password were also passed on to other domains referenced in the index.yaml file. This occurred when Helm went to retrieve a specific chart archive on the other domain. Patches This issue…
Recommended action: Upgrade to 3.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Helm core maintainers have identified a high severity security vulnerability in Go's crypto package affecting all versions prior to Helm 2.16.8 and Helm 3.1.0. Thanks to @ravin9249 for identifying the vulnerability. Impact Go before 1.12.16 and 1.13.x before 1.13.7 (and the crypto/cryptobyte package before 0.0.0-20200124225646-8b5121be2f68 for Go) allows attacks on clients resulting in a panic via a malformed X.509 certificate. This may allow a remote attacker to cause a denial of service. Patches A patch to compile Helm against Go 1.14.4 has been provided for Helm 2 and is available in Helm 2.16.8. Helm 3.1.0 and newer are compiled against Go 1.13.7+. Workarounds No workaround is available. Users are urged to upgrade. References - https://nvd.nist.gov/vuln/detail/CVE-2020-7919 - https://github.com/helm/helm/pull/8288 For more information If you have any questions or comments about this advisory: Open an issue in the Helm repository For security-specific issues, email us at…
Recommended action: Upgrade to 3.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Helm core maintainers have identified an information disclosure vulnerability in Helm 3.0.0-3.1.2. Impact lookup is a Helm template function introduced in Helm v3. It is able to lookup resources in the cluster to check for the existence of specific resources and get details about them. This can be used as part of the process to render templates. The documented behavior of helm template states that it does not attach to a remote cluster. However, as the recently added lookup template function circumvents this restriction and connects to the cluster even during helm template and helm install|update|delete|rollback --dry-run. The user is not notified of this behavior. Running helm template should not make calls to a cluster. This is different from install, which is presumed to have access to a cluster in order to load resources into Kubernetes. Helm 2 is unaffected by this vulnerability. A malicious chart author could inject a lookup into a chart that, when rendered through helm…
Recommended action: Upgrade to 3.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact During a security audit of Helm's code base, Helm maintainers identified a bug in which a Helm plugin can contain duplicates of the same entry, with the last one always used. If a plugin is compromised, this lowers the level of access that an attacker needs to modify a plugin's install hooks, causing a local execution attack. To perform this attack, an attacker must have write access to the git repository or plugin archive (.tgz) while being downloaded (which can occur during a MITM attack on a non-SSL connection). Patches This issue has been patched in Helm 2.16.11 and Helm 3.3.2. Workarounds Make sure to install plugins using a secure connection protocol like SSL.
Recommended action: Upgrade to 3.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Security researchers at Trail of Bits discovered that plugin names are not sanitized properly. As a result, a malicious plugin author could use characters in a plugin name that would result in unexpected behavior, such as duplicating the name of another plugin or spoofing the output to helm --help. Specific Go Packages Affected helm.sh/helm/v3/pkg/plugin Patches This issue has been patched in Helm 3.3.2. Workarounds Do not install untrusted Helm plugins. Examine the name field in the plugin.yaml file for a plugin, looking for characters outside of the [a-zA-Z0-9.-] range.
Recommended action: Upgrade to 3.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact During a security audit of Helm's code base, security researchers at Trail of Bits identified a bug in which the a Helm repository can contain duplicates of the same chart, with the last one always used. If a repository is compromised, this lowers the level of access that an attacker needs to inject a bad chart into a repository. To perform this attack, an attacker must have write access to the index file (which can occur during a MITM attack on a non-SSL connection). Specific Go Packages Affected helm.sh/helm/v3/pkg/repo Patches This issue has been patched in Helm 3.3.2 and 2.16.11 Workarounds - do not install charts from repositories you do not trust - fetch charts using a secure channel of communication (such as TLS) - use helm pull to fetch the chart, then review the chart’s content (either manually, or with helm verify if it has been signed) to ensure it has not been tampered with - manually review the index file in the Helm repository cache before installing software.
Recommended action: Upgrade to 3.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact During a security audit of Helm's code base, security researchers at Trail of Bits identified a bug in which the alias field on a Chart.yaml is not properly sanitized. This could lead to the injection of unwanted information into a chart. Patches This issue has been patched in Helm 3.3.2 and 2.16.11 Specific Go Packages Affected helm.sh/helm/v3/pkg/chartutil Workarounds Manually review the dependencies field of any untrusted chart, verifying that the alias field is either not used, or (if used) does not contain newlines or path characters.
Recommended action: Upgrade to 3.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.