CVE-2026-41053: Rancher GitHub App Auth Over-Inclusive Team Membership Expansion
A logic bug in Rancher's GitHub App authentication provider gives any org member the group permissions of every team in the organization, not just the teams they actually belong to.
The problem
Rancher v2.14.0 and v2.13.0 introduced the GitHub App authentication provider. Its team membership evaluation reads from a shared org-level cache of all teams instead of the per-user membership cache, so every authenticated user receives group principals for every team in the organization.
An attacker only needs a valid GitHub account with membership in at least one low-privilege team. If any other team in the same org is bound to a Rancher allowlist entry, ClusterRoleTemplateBinding, ProjectRoleTemplateBinding, or GlobalRoleBinding, the attacker inherits those permissions automatically on login.
Proof of concept
A working proof-of-concept for CVE-2026-41053 in github.com/rancher/rancher, with the exact payload below.
# No injectable payload exists. The vulnerability is a logic flaw triggered by normal login.
# Preconditions:
# 1. GitHub App auth provider enabled in Rancher.
# 2. Attacker has a GitHub account in team "low-priv-team" (org: target-org).
# 3. A separate team "admin-team" in target-org is bound to a Rancher RBAC role.
#
# Exploitation:
# - Attacker logs in to Rancher via the GitHub App provider as normal.
# - Rancher calls getGroupPrincipals() which iterates ALL teams in target-org
# from the org-wide cache, NOT the user-specific membership cache.
# - Response includes a group principal for "admin-team" even though the
# attacker is not a member of it.
#
# Resulting inflated principals in the User object (example):
# groupPrincipals:
# - githubapp_team://12345 # low-priv-team (legitimate)
# - githubapp_team://67890 # admin-team (illegitimately granted)
#
# The attacker now passes any RBAC or allowlist check tied to admin-team.The root cause (CWE-305 / CWE-287 family, filed as "Incorrect Implementation of Authentication Algorithm") is a one-line iteration mistake in the GitHub App provider's getGroupPrincipals function. The vulnerable code ranged over the org-wide team list stored in the shared cache; the patch (PR #55093, commit 361d4d5) changed that range to iterate only the user-specific team list stored in the per-user membership cache.
Because inflated group principals were persisted on the Rancher User resource, the privilege persisted across sessions until a provider refresh. The patch also ships a one-time startup migration that marks all affected User resources dirty, forcing Rancher to rebuild group principals with the corrected logic on next refresh.
No public PoC is needed: the vulnerability fires on every normal login while the buggy code is present. The attacker does not send any crafted request; the miscalculation happens entirely server-side.
The fix
Upgrade to Rancher v2.14.2 (or v2.13.6 for the 2.13 line). The fix is in PR #55093 (commit 361d4d57) and PR #55147 (commit d0c047bb). After upgrade, Rancher automatically triggers a principal refresh for all affected users.
If immediate upgrade is not possible: disable the GitHub App auth provider and switch to GitHub OAuth, remove team-based group principals from allowedPrincipalIds, and audit or remove RBAC bindings that reference GitHub App team principals.
Reported by samjustus (SUSE Rancher Security Team).
Related research
- critical · 8.4CVE-2026-41052CVE-2026-41052: Rancher Project Owner Privilege Escalation to Host
- high · 7.1CVE-2026-50163CVE-2026-50163: oras-go Hardlink Path Traversal via CWD Resolution
- high · 8.1CVE-2026-50138CVE-2026-50138: goshs WebDAV Mode-Flag Access Control Bypass
- high · 7.5CVE-2026-50151CVE-2026-50151: oras-go Credential Leak via Unvalidated Location Header in Blob Upload