CVE-2026-71404 in Rancher
Summary
by MITRE • 09/03/2026
A flaw was found in Rancher Manager. The GlobalRole controller derived the target ClusterRole name from the user-settable `authz.management.cattle.io/cr-name` annotation and overwrote that object's rules without verifying ownership. A user with delegated GlobalRole create or update permission could point the annotation at any existing ClusterRole, such as `cluster-admin`, and revoke the permissions of every principal bound to it. The change persists after the malicious GlobalRole is deleted.
This issue affects Rancher: before 2.15.1.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified in Rancher Manager prior to version 2.15.1 represents a critical authorization bypass and privilege escalation flaw rooted in improper input validation within the GlobalRole controller logic. The core technical deficiency lies in how the system handles the `authz.management.cattle.io/cr-name` annotation when processing GlobalRole creation or update requests. Instead of validating that the referenced ClusterRole is owned by Rancher or restricted to a specific namespace, the controller blindly accepts any user-provided name and proceeds to overwrite the rules associated with that target object. This lack of ownership verification allows an attacker who possesses delegated permissions to create or modify GlobalRoles to manipulate arbitrary ClusterRole objects within the cluster. The flaw effectively transforms a role management feature into a mechanism for destructive privilege manipulation, as the controller does not distinguish between Rancher-managed roles and user-defined or system-critical roles during the rule application process.
The operational impact of this vulnerability is severe, primarily affecting the integrity of access control policies across Kubernetes clusters managed by Rancher. An attacker with delegated GlobalRole create or update permissions can target high-privilege ClusterRoles such as `cluster-admin`. By pointing the annotation at these critical roles and submitting a malicious GlobalRole configuration, the attacker causes the controller to overwrite the existing rules of the targeted ClusterRole. This action effectively revokes or alters the permissions granted to every principal bound to that specific ClusterRole. Consequently, legitimate administrators may suddenly lose access to cluster resources, leading to service disruption and potential denial of service conditions for critical infrastructure components. Furthermore, because the change persists even after the malicious GlobalRole is deleted, the damage is not easily reversible through simple cleanup operations, requiring manual intervention to restore the original role definitions.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-732 Incorrect Permission Assignment for Critical Resource. The failure to verify ownership before modifying system resources constitutes an authorization bypass that allows lower-privileged users to affect high-privilege objects. In the context of the MITRE ATT&CK framework, this behavior maps to T1098.004 SSH Authorized Key Modification and more broadly to T1531 Account Access Removal, as it involves removing or altering access permissions for existing accounts. It also reflects aspects of T1484 Domain Policy Modification if viewed through the lens of Kubernetes RBAC policy manipulation. The persistence of the change after the triggering object's deletion further exacerbates the severity, resembling a persistent backdoor mechanism that survives standard remediation attempts by simply removing the initial vector of exploitation.
Mitigation strategies must focus on immediate patching and rigorous access control reviews. Organizations running affected versions of Rancher Manager should upgrade to version 2.15.1 or later as soon as possible, where this validation logic has been corrected to ensure that only owned resources are modified by GlobalRole controllers. In the interim, administrators should audit RBAC policies to identify any users with delegated GlobalRole create or update permissions and restrict these privileges to trusted service accounts or highly privileged administrative roles only. Additionally, it is crucial to review existing ClusterRoles for signs of unauthorized rule modifications, particularly those bound to `cluster-admin` or other high-privilege groups. Implementing strict audit logging alerts for changes to RBAC objects can help detect such attempts in real-time, allowing security teams to respond before significant operational damage occurs. Regular backups of cluster configurations are also recommended to facilitate rapid recovery if manual restoration is required due to persistent modifications.