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.
| ID | Description | Date | Resolution |
|---|---|---|---|
| CVE-2024-58259 | POSTs to the Rancher API endpoints are now limited to 1 Mi; this is configurable through the settings if you need a larger limit. The Rancher authentication endpoints are configured independently of the main public API (as you might need bigger payloads in the other API endpoints). Suppose you need to increase the maximum allowed payload for authentication. In that case, you can set the environment variable CATTLE_AUTH_API_BODY_LIMIT to a quantity, e.g., 2 Mi, which would allow larger payloads for the authentication endpoints. | 28 Aug 2025 | Rancher v2.12.1, v2.11.5, v2.10.9 and v2.9.11 |
| CVE-2025-23390 | This vulnerability only affects customers using Continuous Delivery with Fleet where Fleet does not validate a server's certificate when connecting through SSH. This can allow for a main-in-the-middle-attack against Fleet. The fix provides a new insecureSkipHostKeyChecks value for the fleet Helm chart. The default value is set to true (opt-in) for Rancher v2.9 - v2.11 for backward compatibility. The default value is set to false (opt-out) for Rancher v2.12 and later, and Fleet v0.13 and later. true (opt-in):
insecureSkipHostKeyChecks is set to true, then not finding any matching known_hosts entry for an SSH host will not lead to any error. Please note, regardless of the configuration setting, if the known-hosts ConfigMap is deleted it will lead to errors as it will be considered a symptom of an incomplete Fleet deployment. false (opt-out):
insecureSkipHostKeyChecks is set to false, then strict host key checks are enabled. When enabled, the checks ensure that when using SSH, Fleet rejects connection attempts to hosts not matching any entry found in (decreasing order of precedence): This happens regardless of whether a GitRepo uses an SSH URL to point to a Git repository since, once cloned, a repository may be found to contain external resources to be retrieved, such as Helm artifacts. known_hosts entries is that they are only provided for GitHub, Gitlab, Bitbucket and Azure DevOps hosts. If you need to connect to a different host, or if key fingerprints for the provided entries are updated, the following options are available:
| 24 Apr 2025 | Rancher v2.11.1, v2.10.5, and v2.9.9 |
| CVE-2024-22031 | A vulnerability was found where users could create a project and then gain access to arbitrary projects. As a fix, a new field has been added to projects called the BackingNampespace, which represents the namespace created for a project containing all resources needed for project operations. This includes resources such as ProjectRoleTemplateBindings, project-scoped secrets and workloads. The field is populated automatically during project creation and is formatted as <clusterID>-<project.Name>. For example, if your project is named project-abc123 in a cluster with ID cluster-xyz789, then the project will have the BackingNampespace: cluster-xyz789-project-abc123. If the BackingNampespace field is empty then the project will fallback to using the namespace that is the project's name as it did before. Existing projects will not be migrated and only newly created projects will have the new namespace naming convention. If listing projects via kubectl the BackingNampespace will also be listed as a column. | 24 Apr 2025 | Rancher v2.11.1, v2.10.5, and v2.9.9 |
| CVE-2023-32198 | A vulnerability was found where users with permission to create a service in the Kubernetes cluster where Rancher is deployed can take over the Rancher UI, display their own UI, and gather sensitive information. This is only possible when the setting ui-offline-preferred is set to remote. This release introduces a patch, and the malicious user can no longer serve their own UI. If users can't upgrade, please make sure that only trustable users have access to create a service in the local cluster. | 24 Apr 2025 | Rancher v2.11.1, v2.10.5, v2.9.9 and v2.8.15 |
| CVE-2025-23391 | A vulnerability has been identified within Rancher where a Restricted Administrator can change the password of Administrators and take over their accounts. A Restricted Administrator should not be allowed to change the password of more privileged users unless it contains the Manage Users permissions. A new validation has been added to block a user from editing or deleting another user with more permissions than themselves. Rancher deployments where the Restricted Administrator role is not being used are not affected by this CVE. | 31 Mar 2025 | Rancher v2.11.0, v2.10.4, v2.9.8 and v2.8.14 |
| CVE-2025-23389 | A vulnerability in Rancher has been discovered, leading to a local user impersonation through SAML Authentication on first login. The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the User Retention feature with delete-inactive-user-after | 27 Feb 2025 | Rancher v2.10.3, v2.9.7 and v2.8.13 |
| CVE-2025-23388 | An unauthenticated stack overflow crash, leading to a denial of service (DoS), was identified in Rancher’s /v3-public/authproviders public API endpoint. A malicious user could submit data to the API which would cause the Rancher server to crash, but no malicious or incorrect data would actually be written in the API. The downstream clusters, i.e., the clusters managed by Rancher, are not affected by this issue. This vulnerability affects those using external authentication providers as well as Rancher’s local authentication. | 27 Feb 2025 | Rancher v2.10.3, v2.9.7 and v2.8.13 |
| CVE-2025-23387 | A vulnerability has been identified within Rancher where it is possible for an unauthenticated user to list all CLI authentication tokens and delete them before the CLI is able to get the token value. This effectively prevents users from logging in via the CLI when using rancher token as the execution command (instead of the token directly being in the kubeconfig). Note that this token is not the kubeconfig token and if an attacker is able to intercept it they can't use it to impersonate a real user since it is encrypted. | 27 Feb 2025 | Rancher v2.10.3, v2.9.7 and v2.8.13 |
| CVE-2024-52281 | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher v2.10.0 and v2.9.4 |
| CVE-2024-52282 | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. Rancher v2.7 is vulnerable and hasn't received the fix. | 19 Nov 2024 | Rancher v2.9.4 and v2.8.10. |
| CVE-2024-22036 | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the chroot jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher v2.9.3, v2.8.9 and v2.7.16 |
| CVE-2023-32197 | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing BUILTIN\Users or NT AUTHORITY\Authenticated Users to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. Rancher v2.7 is vulnerable and hasn't received the fix. | 24 Oct 2024 | Rancher v2.9.3 and v2.8.9 |
| CVE-2022-45157 | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. Rancher v2.7 is vulnerable and hasn't received the fix. | 24 Oct 2024 | Rancher v2.9.3 and v2.8.9 |
| CVE-2024-22030 | A high severity vulnerability was discovered in Rancher's agents that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker needs to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the server-url of the Rancher cluster). | 19 Sep 2024 | Rancher v2.9.2, v2.8.8 and v2.7.15 |