Like a hotel keycard system that copies every room's access onto any guest's card the moment they check in
CVE-2026-41053 is a logic flaw in Rancher Manager's GitHub App authentication provider (versions 2.13.0–2.13.5 and 2.14.0–2.14.1). When a user authenticates, Rancher converts their GitHub team memberships into internal *group principals* — identity tokens like github_team://acme-corp/prod-admins that drive RBAC bindings. The bug: the expansion code iterates over every team defined in the entire GitHub organization instead of only the teams the user actually belongs to. Any user who is a member of even one low-privilege team (e.g., docs-only) silently receives group principals for every other team in the org — and inherits every Rancher role, project membership, and cluster permission mapped to those teams.
The vendor's HIGH 8.8 is defensible for deployments that actually use GitHub App auth with team-based RBAC, but it overstates fleet-wide risk. The vulnerability only fires through the GitHub App provider — not GitHub OAuth, LDAP, SAML, Active Directory, or local auth. Rancher supports eight auth backends; GitHub App is the newest and least common. The attacker must also already hold a GitHub org membership (PR:L). For the subset of Rancher instances running GitHub App auth, however, the impact is devastating: silent, complete RBAC inheritance across all managed Kubernetes clusters with zero user interaction and no audit-trail signal. That combination — narrow blast surface, catastrophic depth — lands this at a downgraded but firm HIGH.
5 steps from start to impact.
Attacker holds GitHub org membership
docs-contributors suffices.- Valid GitHub account
- Membership in ≥1 team in the target GitHub organization
- Requires insider access or credential compromise of an org member
- GitHub organizations with strict membership governance reduce the pool of potential attackers
Rancher configured with GitHub App auth + team RBAC mappings
- Rancher ≥2.13.0 and <2.13.6 or ≥2.14.0 and <2.14.2
- GitHub App auth provider enabled (not GitHub OAuth)
- ≥1 team mapped to Rancher RBAC roles or login allowlist
- GitHub App auth is a newer provider — many Rancher deployments still use GitHub OAuth, LDAP, SAML, or AD
- Deployments using only org-level (not team-level) RBAC bindings are unaffected
GET /v3/authConfigs reveals active provider type; GET /v3/clusterRoleTemplateBindings reveals team-principal bindingsAttacker authenticates to Rancher
- Network access to Rancher UI/API (typically HTTPS on port 443)
- Rancher behind VPN or private network reduces exposure
- MFA on GitHub account adds friction to credential-compromise scenarios
Rancher expands all org teams into user's principals
github_team://org/team-a, github_team://org/team-b, etc. — regardless of actual membership. No error is logged; the expansion appears normal.- Vulnerable Rancher version processing the login
- None — this is the bug itself; it fires deterministically on every login through the affected provider
GET /v3/principals) against GitHub API team membership (GET /orgs/{org}/teams/{team}/members) — mismatch reveals inflationAttacker inherits all team-mapped RBAC permissions
- Teams mapped to meaningful RBAC roles (cluster-owner, project-admin, etc.)
- Organizations that use minimal team-to-role mappings limit blast radius
- Namespace-level network policies may limit lateral movement within clusters
GET /v3/principals for every authenticated user and compare against actual GitHub team memberships via the GitHub API. Revoke any inflated principals. This is a detection and cleanup measure, not a prevention — users will re-inflate on next login unless combined with a provider switch or patch. Perform immediately as a detection exercise.- GitHub MFA/SSO hardening — MFA protects against credential theft but does not prevent a legitimate org member from exploiting the bug. The attacker IS an authenticated insider; stronger authentication just confirms their identity more thoroughly before granting them inflated permissions.
- Kubernetes NetworkPolicy or pod-level RBAC — These controls operate within clusters, not at the Rancher management plane. The vulnerability grants Rancher-level RBAC, which supersedes in-cluster network segmentation.
- Rancher audit logging alone — The inflated principals produce no anomalous log entries. Standard audit logs will show successful access that appears authorized. Detection requires proactive cross-referencing of Rancher principals against the GitHub API, which is not a standard log-based detection.
The supporting signals.
| In-the-wild exploitation | No evidence. Not listed on CISA KEV. No GreyNoise or Shadowserver tags observed. No campaigns attributed to this CVE as of 2026-09-27. |
|---|---|
| Proof-of-concept availability | None public. No repositories found on GitHub named after CVE-2026-41053. Not indexed on pocindex.io, ExploitDB, or nuclei-templates. The bex.co analysis describes the attack path in detail but does not publish exploit code. No weaponized tooling exists — exploitation requires only a normal login, making a traditional PoC unnecessary. |
| EPSS score | 0.00524 (0.524%) — indicates low predicted exploitation probability in the next 30 days. Roughly 40th–50th percentile across all scored CVEs. |
| KEV status | Not listed. No CISA Known Exploited Vulnerabilities entry as of 2026-09-27. |
| CVSS vector interpretation | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — Network-reachable, low complexity, requires low privileges (any org team member), no user interaction. Full CIA impact within the Rancher authorization scope. Scope Unchanged means impact is confined to the vulnerable component's authorization boundary, though that boundary controls multiple Kubernetes clusters. |
| Affected versions | Rancher 2.13.0–2.13.5 and 2.14.0–2.14.1 (including all pre-releases and RCs in those ranges). Older release lines (2.12.x and below) are not affected — the GitHub App auth provider was introduced in 2.13. |
| Fixed versions | v2.13.6 and v2.14.2 (released 2026-05-27, approximately one month before public disclosure on 2026-06-30). Fix corrects team iteration logic to reference per-user membership cache and includes a startup migration forcing user principal refresh. |
| Exposure surface | Rancher is used by ~4,500+ enterprises (Datanyze). Not all expose the UI to the internet. Of those, only a subset use GitHub App auth (vs. GitHub OAuth, LDAP, SAML, AD, local). Shodan/Censys queries for Rancher login pages return internet-facing instances, but the GitHub App auth subset is not externally distinguishable. |
| Disclosure timeline | Patches shipped 2026-05-27. Public advisory (GHSA-4j6x-2764-m8gh) published 2026-06-30. NVD entry published same day. ~90 days since disclosure as of this assessment. |
| Reporter | Not publicly credited in the GHSA advisory or OSV record. SUSE internal security contact ([email protected]) listed as CNA contact. |
Sources.
Why this verdict
- Auth-provider narrowing: The vulnerability only affects the GitHub App authentication provider — one of eight supported Rancher auth backends. GitHub App auth was introduced in 2.13 and is materially less deployed than GitHub OAuth, LDAP, or SAML. This narrows the vulnerable population to an estimated 10–20% of Rancher installations, justifying a ~0.5–1.0 point reduction from the vendor baseline.
- Insider prerequisite: PR:L requires membership in at least one GitHub org team. This is an authenticated-insider or compromised-credential scenario. While the CVSS vector correctly reflects PR:L, the practical population of potential attackers is bounded by GitHub org membership — typically tens to low hundreds of developers per org, not the entire internet.
- No exploitation signal: EPSS 0.524%, no KEV listing, no public PoC, no GreyNoise/Shadowserver tags, no attributed campaigns. The vulnerability has been public for ~90 days with zero observed exploitation. The attack requires no tooling (just a login), so the absence of exploitation suggests limited attacker interest or limited exposed surface.
- Role multiplier: Rancher is canonically a Kubernetes orchestration platform — it directly manages multiple Kubernetes clusters, their workloads, secrets, and RBAC. For deployments using GitHub App auth with team-based RBAC, the blast radius is fleet-scale: a single compromised login can yield cluster-admin across every managed cluster. This places Rancher in the high-value orchestration role category (≥10% of installs are managing production clusters by definition), setting a verdict floor of HIGH. The chain succeeds trivially in this role — no additional friction beyond the login itself.
- Silent escalation amplifier: The vulnerability produces no audit-trail signal — no failed-authz events, no permission-denied logs. The attacker's inflated principals look identical to legitimate ones. This makes post-compromise detection difficult without proactive principal-to-GitHub-membership comparison, which most deployments do not perform.
Why not higher?
CRITICAL would require either active exploitation evidence, a broader blast surface, or removal of the authentication prerequisite. The vulnerability is gated behind GitHub App auth provider selection (subset of deployments) AND GitHub org membership (insider or compromised credential). The 90-day window with zero exploitation and an EPSS of 0.5% provides no urgency signal that would override the friction-based downgrade. If this were exploitable by an unauthenticated attacker or affected all auth providers, CRITICAL would be warranted.
Why not lower?
Rancher is a Kubernetes orchestration platform — the canonical high-value role for this class of software. For affected deployments, the attack is trivially easy (just log in), the escalation is silent, and the blast radius is fleet-scale across all managed clusters. The verdict floor is HIGH based on the role-multiplier rule. Dropping to MEDIUM would require evidence that <1% of Rancher installations use GitHub App auth with team RBAC bindings, which no available data supports.
Crowdsourced verification payload.
Run this script on any host with kubectl access to the Rancher management cluster (the cluster where Rancher server pods run) or curl access to the Rancher API. No special privileges beyond a valid Rancher API token or kubeconfig are required. Example: bash check_cve_2026_41053.sh https://rancher.example.com token-xxxxx:yyyyyyyy
#!/usr/bin/env bash
# check_cve_2026_41053.sh — Detect CVE-2026-41053 (Rancher GitHub App auth team expansion)
# Usage: bash check_cve_2026_41053.sh <RANCHER_URL> <API_TOKEN>
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -euo pipefail
RANCHER_URL="${1:-}"
API_TOKEN="${2:-}"
if [[ -z "$RANCHER_URL" || -z "$API_TOKEN" ]]; then
echo "Usage: $0 <RANCHER_URL> <API_TOKEN>"
echo " RANCHER_URL: e.g. https://rancher.example.com"
echo " API_TOKEN: e.g. token-xxxxx:yyyyyyyy"
exit 2
fi
# Strip trailing slash
RANCHER_URL="${RANCHER_URL%/}"
# Fetch Rancher server version
VERSION_JSON=$(curl -sk -H "Authorization: Bearer ${API_TOKEN}" "${RANCHER_URL}/v3/settings/server-version" 2>/dev/null || true)
if [[ -z "$VERSION_JSON" ]]; then
echo "UNKNOWN — Could not connect to Rancher API at ${RANCHER_URL}"
exit 2
fi
SERVER_VERSION=$(echo "$VERSION_JSON" | grep -oP '"value"\s*:\s*"\K[^"]+' || true)
if [[ -z "$SERVER_VERSION" ]]; then
echo "UNKNOWN — Could not parse server version from API response"
exit 2
fi
echo "Rancher version detected: ${SERVER_VERSION}"
# Check auth provider type
AUTH_JSON=$(curl -sk -H "Authorization: Bearer ${API_TOKEN}" "${RANCHER_URL}/v3/authConfigs" 2>/dev/null || true)
GITHUB_APP_ENABLED=$(echo "$AUTH_JSON" | grep -c '"githubapp"' || echo "0")
# Strip leading 'v' if present
VER="${SERVER_VERSION#v}"
# Parse major.minor.patch
IFS='.' read -r MAJOR MINOR PATCH <<< "$(echo "$VER" | grep -oP '^[0-9]+\.[0-9]+\.[0-9]+')"
if [[ -z "$MAJOR" || -z "$MINOR" || -z "$PATCH" ]]; then
echo "UNKNOWN — Could not parse version components from '${SERVER_VERSION}'"
exit 2
fi
# Determine vulnerability status
VULNERABLE=false
if [[ "$MAJOR" -eq 2 && "$MINOR" -eq 13 ]]; then
if [[ "$PATCH" -lt 6 ]]; then
VULNERABLE=true
fi
elif [[ "$MAJOR" -eq 2 && "$MINOR" -eq 14 ]]; then
if [[ "$PATCH" -lt 2 ]]; then
VULNERABLE=true
fi
fi
if [[ "$VULNERABLE" == "true" ]]; then
if [[ "$GITHUB_APP_ENABLED" -gt 0 ]]; then
echo "VULNERABLE — Rancher ${SERVER_VERSION} is in the affected range AND GitHub App auth provider appears enabled. CVE-2026-41053 is exploitable."
exit 1
else
echo "VULNERABLE — Rancher ${SERVER_VERSION} is in the affected version range, but GitHub App auth provider does not appear active. The code bug exists but is not reachable without the provider enabled. Upgrade recommended."
exit 1
fi
else
echo "PATCHED — Rancher ${SERVER_VERSION} is not in the affected range for CVE-2026-41053."
exit 0
fi