Rancher vulnerabilities

A privilege escalation vulnerability exists in Rancher's impersonation middleware (pkg/auth/requests/impersonate.go). An authenticated Rancher user with the default user global role can gain full administrative access to the Rancher control plane and transitively to all downstream clusters it manages. This issue affects Rancher: from 2.11.0 before 2.11.16, from 2.12.0 before 2.12.12, from 2.13.0 before 2.13.8, and from 2.14.0 before 2.14.2.

In Rancher, a user with the ability to create a project on a certain cluster can create a project with the same name as an existing project in a different cluster. This results in the user gaining access to the other project in the different cluster, leading to privilege escalation, because the namespace used on the local cluster to store related resources (PRTBs and secrets) is the name of the project.

When API audit logging is enabled in Rancher Manager, the middleware reads the entire HTTP request body into memory without enforcing a size limit on login endpoints. Because the audit middleware is positioned earlier than APIBodyLimitingHandler, the body-size cap is bypassed. An unauthenticated attacker can send arbitrarily large request bodies to public login endpoints, causing memory exhaustion and termination of the Rancher Manager process.

Rancher issues long-lived registration tokens to authenticate nodes and agents joining a downstream cluster. These tokens were stored and exposed in plaintext with no expiration, so a malicious user could obtain one through the Rancher API, etcd, stored automation, or direct file access on a node, and use it at any time to register a rogue node into the cluster.

Rancher has a denial-of-service vulnerability in multiple TLS listeners. dynamiclistener automatically appends to each serving certificate any hostname presented via SNI, allowing an unauthenticated attacker to send a large number of TLS requests with distinct hostnames, causing the certificate to accumulate an unbounded number of SANs. Eventually, the certificate grows large enough that TLS handshakes fail, causing denial of service.

A missing clean-up in the legacy Project Role Template Binding (PRTB) reconciler in Rancher versions 2.13.0 up to 2.13.7 and 2.14.0 up to 2.14.3 allowed users to retain unauthorized Pod Security Admission (PSA) permissions after an administrator removes those permissions from a RoleTemplate.

A SAML authentication replay vulnerability in Rancher's Assertion Consumer Service (ACS) handler did not enforce one-time use of SAML assertion, potentially allowing person-in-the-middle attacks. Affects Rancher 2.14.0 before 2.14.3.

Incorrect authentication caching in the team membership expansion of the Rancher Github authentication provider caused granting principal access to any logged in user, in 2.13 before 2.13.6 and 2.14 before 2.14.2.

In Rancher versions 2.14 before 2.14.2, 2.13 before 2.13.6, and 2.12 before 2.12.10, users with the Project Owner role can exploit improper privilege handling to escalate their privileges.