Skip to content

GHSA-5qmp-9x47-92q8 CVE-2025-23387 GO-2025-3489

Rancher's SAML-based login via CLI can be denied by unauthenticated users

Medium Go
Severity
5.3 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
0.59%
Chance of exploitation in the next 30 days. Higher than 48.29% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
Fix
2.8.13
Upgrade github.com/rancher/rancher to this version or later

Description

Impact

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.

This happens because for SAML-based authentication providers, the login flow from the CLI works by generating a link to be pasted in the browser, and then polling every 10 seconds for the /v3-public/authTokens/<token name> endpoint. The <token name> is randomly generated by the CLI. Once the login flow succeeds, Rancher creates an auth token (with an encrypted token value). The CLI then deletes the authToken.

Rancher deployments using only the local authentication provider, or non-SAML-based authentication providers, are not impacted by this vulnerability. SAML-based users not using the CLI are also not impacted.

Please consult the associated MITRE ATT&CK - Technique - Account Access Removal for further information about this category of attack.

Patches

The fix involves removing GET and DELETE methods for the authTokens collection.

Patched versions include releases v2.8.13, v2.9.7 and v2.10.3.

Workarounds

Users can refrain from using the Rancher CLI to log in as a workaround. Otherwise, users are advised to upgrade to a patched version of Rancher Manager.

References

If you have any questions or comments about this advisory:

Affected versions

Go

PackageVulnerableFixed in
github.com/rancher/rancher
>= 2.8.0, < 2.8.13
2.8.13
github.com/rancher/rancher
>= 2.9.0, < 2.9.7
2.9.7
github.com/rancher/rancher
>= 2.10.0, < 2.10.3
2.10.3
github.com/rancher/rancher
all versions
No fix yet

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/rancher/rancher Go → 2.8.13

go
go get github.com/rancher/rancher@v2.8.13 && go mod tidy

Severity breakdown

CVSS 3.1 5.3

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
Low

Weakness

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

How to prevent it
  • Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-4j6x-2764-m8gh
Rancher has over-inclusive team membership expansion in GitHub App authentication provider
High Also affects github.com/rancher/rancher
GHSA-vx8h-4prv-g744
Rancher has Privilege Escalation from Project Owner to Host
High Also affects github.com/rancher/rancher
GHSA-mhc6-2gfq-xx62
Rancher vulnerable to command injection through unsanitized YAML parameter
Critical Also affects github.com/rancher/rancher
GHSA-5v3h-x4wf-5c35
Rancher Extensions have arbitrary file access via path traversal
High Also affects github.com/rancher/rancher
GHSA-gqf8-rvrh-g7w6
Rancher cloud credentials can be used through proxy API by users without access
Critical Also affects github.com/rancher/rancher
GHSA-hwm2-4ph6-w6m5
Rancher's restricted PodSecurityPolicy does not prevent containers from running as a privileged user
High Also affects github.com/rancher/rancher
GHSA-mc24-7m59-4q5p
Rancher CLI skips TLS verification on Rancher CLI login command
Medium Also affects github.com/rancher/rancher
GHSA-mw39-9qc2-f7mg
Rancher exposes sensitive information through audit logs
Medium Also affects github.com/rancher/rancher
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor