Summary
Rancher contains an authorization flaw that can allow a user who is permitted to create a project on one cluster to create a project with the same name as an existing project on another cluster. Under affected project and cluster configurations, this name collision may grant access to resources belonging to the other project and enable privilege escalation.
Rancher contains an authorization flaw that can allow a user who is permitted to create a project on one cluster to create a project with the same name as an existing project on another cluster. Under affected project and cluster configurations, this name collision may grant access to resources belonging to the other project and enable privilege escalation.
Affected context
The issue occurs in Rancher environments where project-related resources, including project role bindings and secrets, are stored in a local cluster namespace derived from the project name. Risk is present when project names are not unique across the relevant cluster scope and authorization checks do not adequately bind resource ownership to the originating cluster and project identity.
The issue occurs in Rancher environments where project-related resources, including project role bindings and secrets, are stored in a local cluster namespace derived from the project name. Risk is present when project names are not unique across the relevant cluster scope and authorization checks do not adequately bind resource ownership to the originating cluster and project identity.
Exploit preconditions
- Attack surface: Rancher project creation and project-resource authorization
workflows
- Required access: Permission to create a project on at least one affected
cluster
- Trigger point: Creation of a project whose name matches a project on another
cluster
- Why exploitation is possible: Project-related namespaces and resources are
identified by a name that may collide across clusters, allowing authorization
context to be confused and access controls to be applied to the wrong
project
- Attack surface: Rancher project creation and project-resource authorization
workflows
- Required access: Permission to create a project on at least one affected
cluster
- Trigger point: Creation of a project whose name matches a project on another
cluster
- Why exploitation is possible: Project-related namespaces and resources are
identified by a name that may collide across clusters, allowing authorization
context to be confused and access controls to be applied to the wrong
project
Why this happens
The underlying defect is an authorization and resource-identity design flaw. Rancher uses the project name as a namespace for associated resources such as project role bindings and secrets, without sufficiently incorporating the cluster context or another globally unambiguous project identifier. This can cause resources from distinct security domains to be treated as belonging to the same project, mapping to CWE-863, Incorrect Authorization.
The underlying defect is an authorization and resource-identity design flaw. Rancher uses the project name as a namespace for associated resources such as project role bindings and secrets, without sufficiently incorporating the cluster context or another globally unambiguous project identifier. This can cause resources from distinct security domains to be treated as belonging to the same project, mapping to CWE-863, Incorrect Authorization.
Potential impact
- An attacker may gain unauthorized access to another project's resources.
- A user could potentially obtain permissions or secrets associated with the other project.
- Project isolation between clusters may be weakened.
- An attacker could use inherited access to perform unauthorized administrative or workload operations.
- An attacker may gain unauthorized access to another project's resources.
- A user could potentially obtain permissions or secrets associated with the other project.
- Project isolation between clusters may be weakened.
- An attacker could use inherited access to perform unauthorized administrative or workload operations.
General mitigation guidance
Mitigation generally focuses on making resource identity and authorization decisions independent of user-controlled names. Secure-by-default designs should use immutable, globally unique project identifiers that include cluster or tenant context, and should verify ownership and scope at every resource access. Project names should be treated as display metadata rather than authorization keys. Access should follow least-privilege principles, with narrowly scoped project-creation permissions and separate controls for secrets, role bindings, and cluster administration.
Mitigation generally focuses on making resource identity and authorization decisions independent of user-controlled names. Secure-by-default designs should use immutable, globally unique project identifiers that include cluster or tenant context, and should verify ownership and scope at every resource access. Project names should be treated as display metadata rather than authorization keys. Access should follow least-privilege principles, with narrowly scoped project-creation permissions and separate controls for secrets, role bindings, and cluster administration.
How teams detect issues like this
Detection can include static and architectural review for authorization lookups keyed only by names, namespace reuse across clusters, or missing tenant and cluster-boundary checks. Code review should examine project creation, namespace generation, role-binding access, and secret retrieval paths for stable identity and ownership validation. Runtime monitoring can flag duplicate project names across clusters, unexpected access to cross-cluster project resources, and project-creation events followed by privilege changes. Policy enforcement can require globally unique resource identifiers and explicit cluster-scope authorization checks. Automated security review tools may help identify name-based authorization patterns.
Detection can include static and architectural review for authorization lookups keyed only by names, namespace reuse across clusters, or missing tenant and cluster-boundary checks. Code review should examine project creation, namespace generation, role-binding access, and secret retrieval paths for stable identity and ownership validation. Runtime monitoring can flag duplicate project names across clusters, unexpected access to cross-cluster project resources, and project-creation events followed by privilege changes. Policy enforcement can require globally unique resource identifiers and explicit cluster-scope authorization checks. Automated security review tools may help identify name-based authorization patterns.
Sources
| Source | Link |
|---|---|
| bugzilla. | bugzilla.suse.com/ |
| github. | github.com/ |
