Summary
Rancher generated tokens not revoked after modifications made to authentication provider
Workarounds
If you cannot update to a patched Rancher version, the recommended workaround is to review and remove tokens associated with auth providers manually.
The tokens can be reviewed by executing kubectl get tokens in Rancher's local cluster. Each found token must be manually reviewed to check if it belongs to a user from a disabled auth provider or a user who's access was previously removed from the auth provider (when the auth provider is still enabled and is or was configured to use access level scopes, as mentioned above). The identified tokens can be removed with kubectl delete tokens <token_name>.
It is important to mention that this workaround must be done every time an auth provider is disabled in case you cannot update to a patched version.
For more information
If you have any questions or comments about this advisory:
- Reach out to SUSE Rancher Security team for security related inquiries.
- Open an issue in Rancher repository.
- Verify our support matrix and product support lifecycle.
Impact
This 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. This allows users to retain access to Rancher and kubectl access to clusters managed by Rancher, according to their previous configured permissions, even after they are supposed to have lost it due to the auth provider been disabled.
The problem also occurs if the auth provider is configured (and is still enabled) to use the access level scopes allow members of clusters and projects, plus authorized users & groups and restrict access to only the authorized users & groups. In this case, removing users and groups from the authorized lists will not revoke the access tokens and they will remain valid.
An example scenario is:
- OpenLDAP, MS Active Directory (AD) or any other external authentication provider is configured as an auth provider.
- A user (
cluster-owner) is grantedcluster-ownerpermissions on a downstream cluster (test-cluster). cluster-ownerlogs in using their external auth provider username and password.cluster-ownergenerates akubeconfigtoken fortest-cluster.- The configured external auth provider is disabled.
In this scenario, the kubeconfig generated in step 4 will still be valid after step 5, and test-cluster can still be accessed using the kubeconfig token.
By default, tokens for authenticated session have their ttl (time to live) set to 960 minutes, so they will expire after 16 hours. kubeconfig tokens are configured to never expire, and their ttl is set to 0. These configurations can be changed in the Rancher's settings (Configuration > Global Settings > Settings) with the parameters auth-user-session-ttl-minutes and kubeconfig-default-token-ttl-minutes, respectively.
The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.
GHSA-C45C-39F6-6GW9 has a CVSS score of 8.8 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.5.17, 2.6.10, 2.7.1); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Patched versions include releases 2.5.17, 2.6.10, 2.7.1 and later versions. After updating to a patched version, it is highly recommended to review the existing tokens and remove tokens related to disabled auth providers as described above in the workaround section.
Frequently Asked Questions
- What is GHSA-C45C-39F6-6GW9? GHSA-C45C-39F6-6GW9 is a high-severity improper authentication vulnerability in github.com/rancher/rancher (go), affecting versions >= 2.5.0, < 2.5.17. It is fixed in 2.5.17, 2.6.10, 2.7.1. The application does not adequately verify the identity of a user, device, or process before granting access.
- How severe is GHSA-C45C-39F6-6GW9? GHSA-C45C-39F6-6GW9 has a CVSS score of 8.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/rancher/rancher are affected by GHSA-C45C-39F6-6GW9? github.com/rancher/rancher (go) versions >= 2.5.0, < 2.5.17 is affected.
- Is there a fix for GHSA-C45C-39F6-6GW9? Yes. GHSA-C45C-39F6-6GW9 is fixed in 2.5.17, 2.6.10, 2.7.1. Upgrade to this version or later.
- Is GHSA-C45C-39F6-6GW9 exploitable, and should I be worried? Whether GHSA-C45C-39F6-6GW9 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-C45C-39F6-6GW9 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-C45C-39F6-6GW9?
- Upgrade
github.com/rancher/rancherto 2.5.17 or later - Upgrade
github.com/rancher/rancherto 2.6.10 or later - Upgrade
github.com/rancher/rancherto 2.7.1 or later
- Upgrade