Rancher RBAC Bypass Enables Privilege Escalation via Pod Security Admission Manipulation

Vulnerability Description

This vulnerability represents a role-based access control (RBAC) enforcement failure in Rancher Manager's authorization layer. The root cause is improper permission validation that allows Project Owner principals to modify Pod Security Admission (PSA) labels on namespaces—a privileged operation typically restricted to cluster administrators. PSA labels (security.workload.security.io/enforce, audit, warn) control whether containers can run in privileged mode. By downgrading PSA from restricted to privileged, a Project Owner can deploy containers with SecurityContext.privileged=true, which disables critical kernel-level isolation (capabilities, AppArmor, seccomp). This creates a privilege escalation pathway: Project Owner → Namespace PSA control → Privileged container deployment → Host-level resource access → Container breakout → Cluster compromise.

Proof-of-Concept Significance

The PoC demonstrates a multi-stage attack chain with low barrier to entry. The preconditions are minimal: only requiring Project Owner assignment (a commonly delegated role for multi-tenant environments). The exploit proves that Rancher's authorization middleware fails to validate PSA modification requests against intended RBAC boundaries. Notably, this bypasses Kubernetes' native RBAC because Rancher applies custom role abstraction; attackers don't need ClusterRole or Role permissions—they exploit Rancher's delegated access model. The reliability is high because PSA modification is a legitimate Rancher operation; detection evasion is trivial.

Detection Guidance

Log Indicators: Monitor Rancher audit logs for LabelPatch or NamespacePatch operations by Project Owner roles targeting PSA labels (security.workload.security.io/*). Watch for namespace label transitions from restricted or baseline to privileged. Kubernetes API: Log PATCH /api/v1/namespaces/{name} requests with metadata.labels mutations affecting PSA enforcement labels. Pod Indicators: Alert on Pod.spec.securityContext.privileged=true deployments in namespaces where PSA was recently modified. Signature Pattern: source_role=project-owner AND action=modify AND resource=namespace.labels AND label_key~="security.workload" AND label_value="privileged".

Mitigation Steps

1. Immediate: Apply Rancher patches (version-specific; check GHSA-vx8h-4prv-g744 for affected versions).
2. RBAC Hardening: Restrict Project Owner role to exclude PSA label modification permissions; segregate to admin-only operation.
3. Namespace Admission Controller: Deploy a Kubernetes ValidatingWebhookConfiguration to reject PSA label downgrades except from cluster-admin principals, regardless of Rancher authorization.
4. Pod Security Policy/Standards: Enforce cluster-wide PodSecurityPolicy: restricted or SecurityPolicy: restricted as a backstop; configure audit/warn modes to detect violations.
5. RBAC Audit: Audit all Project Owner role assignments; remove unnecessary assignments and implement JIT elevation for privileged namespace operations.
6. Monitoring: Enable Rancher audit logging and forward to SIEM; create alerts for PSA label changes and privileged pod deployments.

Risk Assessment

Likelihood: Very High. This vulnerability has minimal exploitation friction (no complex tooling required), affects multi-tenant SaaS and enterprise Rancher deployments, and targets a commonly-used role. Threat Actor Interest: High—this is a direct path to cluster compromise in shared infrastructure, valuable for supply-chain attacks, lateral movement, and data exfiltration. In-the-Wild Exploitation: Likely within 2–4 weeks of disclosure if patches are not deployed; Kubernetes escape techniques are well-documented and automated tools exist. Blast Radius: Affects all namespaces within the project; containment depends on node isolation and workload blast radius. Production deployments running multi-tenant workloads face critical risk.