U.S. flag   An official website of the United States government
Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock (Dot gov) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

Search Results (Refine Search)

Search Parameters:
  • Results Type: Overview
  • Keyword (text search): helm
  • Search Type: Search All
  • CPE Name Search: false
There are 85 matching records.
Displaying matches 61 through 80.
Vuln ID Summary CVSS Severity
CVE-2020-35558

An issue was discovered in MB connect line mymbCONNECT24, mbCONNECT24 and Helmholz myREX24 and myREX24.virtual through 2.11.2. There is an SSRF in the in the MySQL access check, allowing an attacker to scan for open ports and gain some information about possible credentials.

Published: February 16, 2021; 11:15:13 AM -0500
V4.0:(not available)
V3.1: 7.5 HIGH
V2.0: 5.0 MEDIUM
CVE-2020-35557

An issue in MB connect line mymbCONNECT24, mbCONNECT24 and Helmholz myREX24 and myREX24.virtual in all versions through v2.11.2 allows a logged in user to see devices in the account he should not have access to due to improper use of access validation.

Published: February 16, 2021; 11:15:13 AM -0500
V4.0:(not available)
V3.1: 6.5 MEDIUM
V2.0: 4.0 MEDIUM
CVE-2021-21303

Helm is open-source software which is essentially "The Kubernetes Package Manager". Helm is a tool for managing Charts. Charts are packages of pre-configured Kubernetes resources. In Helm from version 3.0 and before version 3.5.2, there a few cases where data loaded from potentially untrusted sources was not properly sanitized. When a SemVer in the `version` field of a chart is invalid, in some cases Helm allows the string to be used "as is" without sanitizing. Helm fails to properly sanitized some fields present on Helm repository `index.yaml` files. Helm does not properly sanitized some fields in the `plugin.yaml` file for plugins In some cases, Helm does not properly sanitize the fields in the `Chart.yaml` file. By exploiting these attack vectors, 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 upgrade to the fixed version 3.5.2 or later. Those who use Helm as a library should verify that they either sanitize this data on their own, or use the proper Helm API calls to sanitize the data.

Published: February 05, 2021; 5:15:12 PM -0500
V4.0:(not available)
V3.1: 6.8 MEDIUM
V2.0: 3.5 LOW
CVE-2020-26250

OAuthenticator is an OAuth login mechanism for JupyterHub. In oauthenticator from version 0.12.0 and before 0.12.2, the deprecated (in jupyterhub 1.2) configuration `Authenticator.whitelist`, which should be transparently mapped to `Authenticator.allowed_users` with a warning, is instead ignored by OAuthenticator classes, resulting in the same behavior as if this configuration has not been set. If this is the only mechanism of authorization restriction (i.e. no group or team restrictions in configuration) then all authenticated users will be allowed. Provider-based restrictions, including deprecated values such as `GitHubOAuthenticator.org_whitelist` are **not** affected. All users of OAuthenticator 0.12.0 and 0.12.1 with JupyterHub 1.2 (JupyterHub Helm chart 0.10.0-0.10.5) who use the `admin.whitelist.users` configuration in the jupyterhub helm chart or the `c.Authenticator.whitelist` configuration directly. Users of other deprecated configuration, e.g. `c.GitHubOAuthenticator.team_whitelist` are **not** affected. If you see a log line like this and expect a specific list of allowed usernames: "[I 2020-11-27 16:51:54.528 JupyterHub app:1717] Not using allowed_users. Any authenticated user will be allowed." you are likely affected. Updating oauthenticator to 0.12.2 is recommended. A workaround is to replace the deprecated `c.Authenticator.whitelist = ...` with `c.Authenticator.allowed_users = ...`. If any users have been authorized during this time who should not have been, they must be deleted via the API or admin interface, per the referenced documentation.

Published: December 01, 2020; 4:15:14 PM -0500
V4.0:(not available)
V3.1: 6.3 MEDIUM
V2.0: 3.5 LOW
CVE-2020-15187

In Helm before versions 2.16.11 and 3.3.2, 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). This issue has been patched in Helm 2.16.11 and Helm 3.3.2. As a possible workaround make sure to install plugins using a secure connection protocol like SSL.

Published: September 17, 2020; 6:15:12 PM -0400
V4.0:(not available)
V3.1: 4.7 MEDIUM
V2.0: 6.5 MEDIUM
CVE-2020-15186

In Helm before versions 2.16.11 and 3.3.2 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`. This issue has been patched in Helm 3.3.2. A possible workaround is to 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.

Published: September 17, 2020; 6:15:12 PM -0400
V4.0:(not available)
V3.1: 2.7 LOW
V2.0: 4.0 MEDIUM
CVE-2020-15185

In Helm before versions 2.16.11 and 3.3.2, 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). This issue has been patched in Helm 3.3.2 and 2.16.11. A possible workaround is to manually review the index file in the Helm repository cache before installing software.

Published: September 17, 2020; 6:15:12 PM -0400
V4.0:(not available)
V3.1: 2.7 LOW
V2.0: 4.0 MEDIUM
CVE-2020-15184

In Helm before versions 2.16.11 and 3.3.2 there is 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. This issue has been patched in Helm 3.3.2 and 2.16.11. A possible workaround is to 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.

Published: September 17, 2020; 5:15:17 PM -0400
V4.0:(not available)
V3.1: 2.7 LOW
V2.0: 4.0 MEDIUM
CVE-2020-4062

In Conjur OSS Helm Chart before 2.0.0, a recently identified critical vulnerability resulted in the installation of the Conjur Postgres database with an open port. This allows an attacker to gain full read & write access to the Conjur Postgres database, including escalating the attacker's privileges to assume full control. A malicious actor who knows the IP address and port number of the Postgres database and has access into the Kubernetes cluster where Conjur runs can gain full read & write access to the Postgres database. This enables the attacker to write a policy that allows full access to retrieve any secret. This Helm chart is a method to install Conjur OSS into a Kubernetes environment. Hence, the systems impacted are only Conjur OSS systems that were deployed using this chart. Other deployments including Docker and the CyberArk Dynamic Access Provider (DAP) are not affected. To remediate this vulnerability, clone the latest Helm Chart and follow the upgrade instructions. If you are not able to fully remediate this vulnerability immediately, you can mitigate some of the risk by making sure Conjur OSS is deployed on an isolated Kubernetes cluster or namespace. The term "isolated" refers to: - No other workloads besides Conjur OSS and its backend database are running in that Kubernetes cluster/namespace. - Kubernetes and helm access to the cluster/namespace is limited to security administrators via Role-Based Access Control (RBAC).

Published: June 22, 2020; 12:15:11 PM -0400
V4.0:(not available)
V3.1: 9.0 CRITICAL
V2.0: 7.7 HIGH
CVE-2020-14470

In Octopus Deploy 2018.8.0 through 2019.x before 2019.12.2, an authenticated user with could trigger a deployment that leaks the Helm Chart repository password.

Published: June 19, 2020; 12:15:10 PM -0400
V4.0:(not available)
V3.1: 6.5 MEDIUM
V2.0: 4.0 MEDIUM
CVE-2020-4053

In Helm greater than or equal to 3.0.0 and less than 3.2.4, a path 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. This has been fixed in 3.2.4.

Published: June 16, 2020; 6:15:10 PM -0400
V4.0:(not available)
V3.1: 6.8 MEDIUM
V2.0: 8.5 HIGH
CVE-2020-11013

Their is an information disclosure vulnerability in Helm from version 3.1.0 and before version 3.2.0. `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, a 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 template`, performs unannounced lookups against the cluster a user's `KUBECONFIG` file points to. This information can then be disclosed via the output of `helm template`. This issue has been fixed in Helm 3.2.0

Published: April 24, 2020; 4:15:09 PM -0400
V4.0:(not available)
V3.1: 5.0 MEDIUM
V2.0: 4.0 MEDIUM
CVE-2019-18658

In Helm 2.x before 2.15.2, commands that deal with loading a chart as a directory or packaging a chart provide an opportunity for a maliciously designed chart to include sensitive content such as /etc/passwd, or to execute a denial of service (DoS) via a special file such as /dev/urandom, via symlinks. No version of Tiller is known to be impacted. This is a client-only issue.

Published: November 12, 2019; 9:15:11 AM -0500
V4.0:(not available)
V3.1: 9.8 CRITICAL
V2.0: 7.5 HIGH
CVE-2019-1010275

helm Before 2.7.2 is affected by: CWE-295: Improper Certificate Validation. The impact is: Unauthorized clients could connect to the server because self-signed client certs were aloowed. The component is: helm (many files updated, see https://github.com/helm/helm/pull/3152/files/1096813bf9a425e2aa4ac755b6c991b626dfab50). The attack vector is: A malicious client could connect to the server over the network. The fixed version is: 2.7.2.

Published: July 17, 2019; 5:15:10 PM -0400
V4.0:(not available)
V3.0: 9.8 CRITICAL
V2.0: 7.5 HIGH
CVE-2019-1000009

Helm ChartMuseum version >=0.1.0 and < 0.8.1 contains a CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in HTTP API to save charts that can result in a specially crafted chart could be uploaded and saved outside the intended location. This attack appears to be exploitable via A POST request to the HTTP API can save a chart archive outside of the intended directory. If authentication is, optionally, enabled this requires an authorized user to do so. This vulnerability appears to have been fixed in 0.8.1.

Published: February 04, 2019; 4:29:00 PM -0500
V4.0:(not available)
V3.0: 6.5 MEDIUM
V2.0: 4.0 MEDIUM
CVE-2019-1000008

All versions of Helm between Helm >=2.0.0 and < 2.12.2 contains a CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in The commands `helm fetch --untar` and `helm lint some.tgz` that can result when chart archive files are unpacked a file may be unpacked outside of the target directory. This attack appears to be exploitable via a victim must run a helm command on a specially crafted chart archive. This vulnerability appears to have been fixed in 2.12.2.

Published: February 04, 2019; 4:29:00 PM -0500
V4.0:(not available)
V3.0: 6.5 MEDIUM
V2.0: 4.3 MEDIUM
CVE-2007-5251

Multiple cross-site scripting (XSS) vulnerabilities in Helm 3.2.16 allow remote attackers to inject arbitrary web script or HTML via (1) the showOption parameter to domain.asp, or the (2) Folder or (3) StartPath parameter to FileManager.asp.

Published: October 06, 2007; 1:17:00 PM -0400
V4.0:(not available)
V3.x:(not available)
V2.0: 4.3 MEDIUM
CVE-2007-3693

Cross-site scripting (XSS) vulnerability in Gobi as of 20070711, built on Helma, allows remote attackers to inject arbitrary web script or HTML via the q parameter to the search function.

Published: July 11, 2007; 7:30:00 PM -0400
V4.0:(not available)
V3.x:(not available)
V2.0: 4.3 MEDIUM
CVE-2006-5984

Multiple cross-site scripting (XSS) vulnerabilities in Helm Web Hosting Control Panel 3.2.10 allow remote authenticated users to inject arbitrary web script or HTML via the (1) txtCompanyName, (2) txtEmail, or (3) txtUserAccNum parameter to (a) users.asp, or the (4) setThemeColour parameter to (b) default.asp in the Reseller and Admin levels; or the (5) setThemeColour parameter to default.asp in the User level. NOTE: the txtDomainName parameter to domains.asp is covered by CVE-2006-1407, which suggests that this vector is fixed in 3.2.10 stable.

Published: November 20, 2006; 4:07:00 PM -0500
V4.0:(not available)
V3.x:(not available)
V2.0: 6.8 MEDIUM
CVE-2006-1407

Multiple cross-site scripting (XSS) vulnerabilities in Helm Web Hosting Control Panel 3.2.10 and earlier allow remote attackers to inject arbitrary web script or HTML via the (1) txtDomainName parameter to domains.asp or (2) SearchText or (3) UserLevel parameters to default.asp.

Published: March 28, 2006; 6:06:00 AM -0500
V4.0:(not available)
V3.x:(not available)
V2.0: 5.8 MEDIUM