Security Advisories and CVEs

Rancher is committed to informing the community of security issues in our products. Rancher will publish security advisories and CVEs (Common Vulnerabilities and Exposures) for issues we have resolved. New security advisories are also published in Rancher’s GitHub security page.

IDDescriptionDateResolution
CVE-2023-22651The Rancher admissions webhook may become misconfigured due to a failure in the webhook’s update logic. The admissions webhook enforces validation rules and security checks before resources are admitted into the Kubernetes cluster. When the webhook is operating in a degraded state, it no longer validates any resources, which can result in severe privilege escalations and data corruption.24 April 2023Rancher v2.7.3
CVE-2022-43758An issue was discovered in Rancher from versions 2.5.0 up to and including 2.5.16, 2.6.0 up to and including 2.6.9 and 2.7.0, where a command injection vulnerability is present in the Rancher Git package. This package uses the underlying Git binary available in the Rancher container image to execute Git operations. Specially crafted commands, when not properly disambiguated, can cause confusion when executed through Git, resulting in command injection in the underlying Rancher host.24 January 2023Rancher v2.7.1, v2.6.10 and v2.5.17
CVE-2022-43757This issue affects Rancher versions from 2.5.0 up to and including 2.5.16, from 2.6.0 up to and including 2.6.9 and 2.7.0. It was discovered that the security advisory CVE-2021-36782, previously released by Rancher, missed addressing some sensitive fields, secret tokens, encryption keys, and SSH keys that were still being stored in plaintext directly on Kubernetes objects like Clusters. The exposed credentials are visible in Rancher to authenticated Cluster Owners, Cluster Members, Project Owners and Project Members of that cluster.24 January 2023Rancher v2.7.1, v2.6.10 and v2.5.17
CVE-2022-43755An issue was discovered in Rancher versions up to and including 2.6.9 and 2.7.0, where the cattle-token secret, used by the cattle-cluster-agent, is predictable. Even after the token is regenerated, it will have the same value. This can pose a serious problem if the token is compromised and needs to be recreated for security purposes. The cattle-token is used by Rancher’s cattle-cluster-agent to connect to the Kubernetes API of Rancher provisioned downstream clusters.24 January 2023Rancher v2.7.1 and v2.6.10
CVE-2022-21953An issue was discovered in Rancher versions up to and including 2.5.16, 2.6.9 and 2.7.0, where an authorization logic flaw allows an authenticated user on any downstream cluster to (1) open a shell pod in the Rancher local cluster and (2) have limited kubectl access to it. The expected behavior is that a user does not have such access in the Rancher local cluster unless explicitly granted.24 January 2023Rancher v2.7.1, v2.6.10 and v2.5.17
GHSA-c45c-39f6-6gw9This issue affects Rancher versions from 2.5.0 up to and including 2.5.16, from 2.6.0 up to and including 2.6.9 and 2.7.0. It only affects Rancher setups that have an external authentication provider configured or had one configured in the past. It was discovered that when an external authentication provider is configured in Rancher and then disabled, the Rancher generated tokens associated with users who had access granted through the now disabled auth provider are not revoked.24 January 2023Rancher v2.7.1, v2.6.10 and v2.5.17
CVE-2022-31247An issue was discovered in Rancher versions up to and including 2.5.15 and 2.6.6 where a flaw with authorization logic allows privilege escalation in downstream clusters through cluster role template binding (CRTB) and project role template binding (PRTB). The vulnerability can be exploited by any user who has permissions to create/edit CRTB or PRTB (such as cluster-owner, manage cluster members, project-owner, and manage project members) to gain owner permission in another project in the same cluster or in another project on a different downstream cluster.18 August 2022Rancher v2.6.7 and Rancher v2.5.16
CVE-2021-36783It was discovered that in Rancher versions up to and including 2.5.12 and 2.6.3, there is a failure to properly sanitize credentials in cluster template answers. This failure can lead to plaintext storage and exposure of credentials, passwords, and API tokens. The exposed credentials are visible in Rancher to authenticated Cluster Owners, Cluster Members, Project Owners, and Project Members on the endpoints /v1/management.cattle.io.clusters, /v3/clusters, and /k8s/clusters/local/apis/management.cattle.io/v3/clusters.18 August 2022Rancher v2.6.7 and Rancher v2.5.16
CVE-2021-36782An issue was discovered in Rancher versions up to and including 2.5.15 and 2.6.6 where sensitive fields like passwords, API keys, and Rancher’s service account token (used to provision clusters) were stored in plaintext directly on Kubernetes objects like Clusters (e.g., cluster.management.cattle.io). Anyone with read access to those objects in the Kubernetes API could retrieve the plaintext version of those sensitive data. The issue was partially found and reported by Florian Struck (from Continum AG) and Marco Stuurman (from Shock Media B.V.).18 August 2022Rancher v2.6.7 and Rancher v2.5.16
CVE-2022-21951This vulnerability only affects customers using Weave Container Network Interface (CNI) when configured through RKE templates. A vulnerability was discovered in Rancher versions 2.5.0 up to and including 2.5.13, and 2.6.0 up to and including 2.6.4, where a user interface (UI) issue with RKE templates does not include a value for the Weave password when Weave is chosen as the CNI. If a cluster is created based on the mentioned template, and Weave is configured as the CNI, no password will be created for network encryption in Weave; therefore, network traffic in the cluster will be sent unencrypted.24 May 2022Rancher v2.6.5 and Rancher v2.5.14
CVE-2021-36784A vulnerability was discovered in Rancher versions from 2.5.0 up to and including 2.5.12 and from 2.6.0 up to and including 2.6.3 which allows users who have create or update permissions on Global Roles to escalate their permissions, or those of another user, to admin-level permissions. Global Roles grant users Rancher-wide permissions, such as the ability to create clusters. In the identified versions of Rancher, when users are given permission to edit or create Global Roles, they are not restricted to only granting permissions which they already posses. This vulnerability affects customers who utilize non-admin users that are able to create or edit Global Roles. The most common use case for this scenario is the restricted-admin role.14 Apr 2022Rancher v2.6.4 and Rancher v2.5.13
CVE-2021-4200This vulnerability only affects customers using the restricted-admin role in Rancher. A vulnerability was discovered in Rancher versions from 2.5.0 up to and including 2.5.12 and from 2.6.0 up to and including 2.6.3 where the global-data role in cattle-global-data namespace grants write access to the Catalogs. Since each user with any level of catalog access was bound to the global-data role, this grants write access to templates (CatalogTemplates) and template versions (CatalogTemplateVersions) for any user with any level of catalog access. New users created in Rancher are by default assigned to the user role (standard user), which is not designed to grant write catalog access. This vulnerability effectively elevates the privilege of any user to write access for the catalog template and catalog template version resources.14 Apr 2022Rancher v2.6.4 and Rancher v2.5.13
GHSA-wm2r-rp98-8pmhThis vulnerability only affects customers using Fleet for continuous delivery with authenticated Git and/or Helm repositories. An issue was discovered in go-getter library in versions prior to v1.5.11 that exposes SSH private keys in base64 format due to a failure in redacting such information from error messages. The vulnerable version of this library is used in Rancher through Fleet in versions of Fleet prior to v0.3.9. This issue affects Rancher versions 2.5.0 up to and including 2.5.12 and from 2.6.0 up to and including 2.6.3. The issue was found and reported by Dagan Henderson from Raft Engineering.14 Apr 2022Rancher v2.6.4 and Rancher v2.5.13
CVE-2021-36778A vulnerability was discovered in Rancher versions from 2.5.0 up to and including 2.5.11 and from 2.6.0 up to and including 2.6.2, where an insufficient check of the same-origin policy when downloading Helm charts from a configured private repository can lead to exposure of the repository credentials to a third-party provider. This issue only happens when the user configures access credentials to a private repository in Rancher inside Apps & Marketplace > Repositories. The issue was found and reported by Martin Andreas Ullrich.14 Apr 2022Rancher v2.6.3 and Rancher v2.5.12
GHSA-hwm2-4ph6-w6m5A vulnerability was discovered in versions of Rancher starting 2.0 up to and including 2.6.3. The restricted pod security policy (PSP) provided in Rancher deviated from the upstream restricted policy provided in Kubernetes on account of which Rancher’s PSP had runAsUser set to runAsAny, while upstream had runAsUser set to MustRunAsNonRoot. This allowed containers to run as any user, including a privileged user (root), even when Rancher’s restricted policy was enforced on a project or at the cluster level.31 Mar 2022Rancher v2.6.4
CVE-2021-36775A vulnerability was discovered in Rancher versions up to and including 2.4.17, 2.5.11 and 2.6.2. After removing a Project Role associated with a group from the project, the bindings that granted access to cluster-scoped resources for those subjects were not deleted. This was due to an incomplete authorization logic check. A user who was a member of the affected group with authenticated access to Rancher could exploit this vulnerability to access resources they shouldn’t have had access to. The exposure level would depend on the original permission level granted to the affected project role. This vulnerability only affected customers using group based authentication in Rancher.31 Mar 2022Rancher v2.6.3, Rancher v2.5.12 and Rancher v2.4.18
CVE-2021-36776A vulnerability was discovered in Rancher versions starting 2.5.0 up to and including 2.5.9, that allowed an authenticated user to impersonate any user on a cluster through an API proxy, without requiring knowledge of the impersonated user’s credentials. This was due to the API proxy not dropping the impersonation header before sending the request to the Kubernetes API. A malicious user with authenticated access to Rancher could use this to impersonate another user with administrator access in Rancher, thereby gaining administrator level access to the cluster.31 Mar 2022Rancher v2.6.0 and Rancher v2.5.10
CVE-2021-25318A vulnerability was discovered in Rancher versions 2.0 through the aforementioned fixed versions, where users were granted access to resources regardless of the resource’s API group. For example, Rancher should have allowed users access to apps.catalog.cattle.io, but instead incorrectly gave access to apps.*. Resources affected in the Downstream clusters and Rancher management cluster can be found here. There is not a direct mitigation besides upgrading to the patched Rancher versions.14 Jul 2021Rancher v2.5.9 and Rancher v2.4.16
CVE-2021-31999A vulnerability was discovered in Rancher 2.0.0 through the aforementioned patched versions, where a malicious Rancher user could craft an API request directed at the proxy for the Kubernetes API of a managed cluster to gain access to information they do not have access to. This is done by passing the “Impersonate-User” or “Impersonate-Group” header in the Connection header, which is then correctly removed by the proxy. At this point, instead of impersonating the user and their permissions, the request will act as if it was from the Rancher management server and incorrectly return the information. The vulnerability is limited to valid Rancher users with some level of permissions on the cluster. There is not a direct mitigation besides upgrading to the patched Rancher versions.14 Jul 2021Rancher v2.5.9 and Rancher v2.4.16
CVE-2021-25320A vulnerability was discovered in Rancher 2.2.0 through the aforementioned patched versions, where cloud credentials weren’t being properly validated through the Rancher API. Specifically through a proxy designed to communicate with cloud providers. Any Rancher user that was logged-in and aware of a cloud-credential ID that was valid for a given cloud provider, could call that cloud provider’s API through the proxy API, and the cloud-credential would be attached. The exploit is limited to valid Rancher users. There is not a direct mitigation outside of upgrading to the patched Rancher versions.14 Jul 2021Rancher v2.5.9 and Rancher v2.4.16
CVE-2021-25313A security vulnerability was discovered on all Rancher 2 versions. When accessing the Rancher API with a browser, the URL was not properly escaped, making it vulnerable to an XSS attack. Specially crafted URLs to these API endpoints could include JavaScript which would be embedded in the page and execute in a browser. There is no direct mitigation. Avoid clicking on untrusted links to your Rancher server.2 Mar 2021Rancher v2.5.6, Rancher v2.4.14, and Rancher v2.3.11
CVE-2019-14435This vulnerability allows authenticated users to potentially extract otherwise private data out of IPs reachable from system service containers used by Rancher. This can include but not only limited to services such as cloud provider metadata services. Although Rancher allow users to configure whitelisted domains for system service access, this flaw can still be exploited by a carefully crafted HTTP request. The issue was found and reported by Matt Belisle and Alex Stevenson at Workiva.5 Aug 2019Rancher v2.2.7 and Rancher v2.1.12
CVE-2019-14436The vulnerability allows a member of a project that has access to edit role bindings to be able to assign themselves or others a cluster level role granting them administrator access to that cluster. The issue was found and reported by Michal Lipinski at Nokia.5 Aug 2019Rancher v2.2.7 and Rancher v2.1.12
CVE-2019-13209The vulnerability is known as a Cross-Site Websocket Hijacking attack. This attack allows an exploiter to gain access to clusters managed by Rancher with the roles/permissions of a victim. It requires that a victim to be logged into a Rancher server and then access a third-party site hosted by the exploiter. Once that is accomplished, the exploiter is able to execute commands against the Kubernetes API with the permissions and identity of the victim. Reported by Matt Belisle and Alex Stevenson from Workiva.15 Jul 2019Rancher v2.2.5, Rancher v2.1.11 and Rancher v2.0.16
CVE-2019-12303Project owners can inject extra fluentd logging configurations that makes it possible to read files or execute arbitrary commands inside the fluentd container. Reported by Tyler Welton from Untamed Theory.5 Jun 2019Rancher v2.2.4, Rancher v2.1.10 and Rancher v2.0.15
CVE-2019-12274Nodes using the built-in node drivers using a file path option allows the machine to read arbitrary files including sensitive ones from inside the Rancher server container.5 Jun 2019Rancher v2.2.4, Rancher v2.1.10 and Rancher v2.0.15
CVE-2019-11202The default admin, that is shipped with Rancher, will be re-created upon restart of Rancher despite being explicitly deleted.16 Apr 2019Rancher v2.2.2, Rancher v2.1.9 and Rancher v2.0.14
CVE-2019-6287Project members continue to get access to namespaces from projects that they were removed from if they were added to more than one project.29 Jan 2019Rancher v2.1.6 and Rancher v2.0.11
CVE-2018-20321Any project member with access to the default namespace can mount the netes-default service account in a pod and then use that pod to execute administrative privileged commands against the Kubernetes cluster.29 Jan 2019Rancher v2.1.6 and Rancher v2.0.11 - Rolling back from these versions or greater have specific instructions.