Rancher Manager GitHub App authentication provider over-expands GitHub organization team memberships

CVE-2026-41053 affects SUSE Rancher Manager / Rancher Manager when the GitHub App authentication provider is enabled. The CNA advisory says affected versions are >=2.14.0, <2.14.2 and >=2.13.0, <2.13.6; fixed releases are 2.14.2 and 2.13.6. The flaw is an authorization bug in team membership expansion: Rancher can hand a logged-in user group principals for all teams in the GitHub organization, not just the teams that user actually belongs to.

The raw CNA score of 8.8 High is too hot for real enterprise triage. In practice this is not unauthenticated remote compromise; it requires a valid GitHub account that is already a member of at least one team in the target org, a Rancher deployment using the newer GitHub App provider, and meaningful Rancher RBAC or login allowlist bindings tied to other teams in that same org. That makes it a dangerous post-auth privilege escalation / authorization bypass, but not a drop-everything internet fire.

Why this verdict

• Baseline starts high, then drops on attacker position: the CNA score is 8.8, but PR:L here really means a valid GitHub org member account already on at least one team. That is post-initial-access or insider territory, not a cold-start internet attacker.
• Feature-gated exposure: only Rancher estates using the GitHub App authentication provider are in play. Organizations using local auth, OIDC, SAML, AD, or the standard GitHub provider are not hit by this path.
• Impact is mapping-dependent: the bug only becomes dangerous when other GitHub teams in the same org are actually tied to Rancher allowedPrincipalIds or RBAC roles. No privileged team bindings, no meaningful privilege jump.
• Blast radius can still be meaningful: when privileged teams are mapped, a low-tier GitHub team member can inherit project, cluster, or even global Rancher privileges. That is enough to expose kubeconfigs, secrets, workloads, and managed cluster operations.

Why not higher?

There is no unauthenticated path, no code execution, and no evidence of active exploitation. The attacker must already be a valid member of the target GitHub organization and the vulnerable population is narrowed further by a specific auth-provider choice and local RBAC design.

Why not lower?

This is still an authorization failure inside a control plane product. In environments that map powerful Rancher roles to GitHub teams, the outcome is not cosmetic; it can become real privilege escalation into cluster and project administration with downstream access to sensitive workloads and secrets.

1. Audit GitHub App usage — Identify Rancher instances using the GitHub App authentication provider and confirm whether they run affected versions. Because this is a MEDIUM finding, there is no mitigation SLA — go straight to the 365-day remediation window, but do this discovery work early so the issue does not disappear into backlog.
2. Trim team-based role bindings — Review GlobalRoleBindings, ClusterRoleTemplateBindings, ProjectRoleTemplateBindings, and login allowlists that reference GitHub App team principals, then remove unnecessary high-privilege mappings. There is no mitigation SLA — go straight to the 365-day remediation window, but this is the cleanest way to reduce blast radius before the upgrade lands.
3. Prefer alternate auth temporarily — If a high-risk Rancher instance heavily depends on GitHub team mappings, consider switching that instance to another supported auth provider or disabling GitHub App auth until the maintenance window. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window; use this only where the RBAC design makes the risk non-trivial.
4. Review inherited access after upgrade — The fix triggers a principal refresh, so validate that formerly over-broad team-derived access is gone and privileged roles are still correctly assigned. There is no mitigation SLA — go straight to the 365-day remediation window, but post-upgrade verification matters because this bug lives in identity state, not just package version.

Run this from an auditor/admin workstation that has kubectl access to the Kubernetes cluster hosting Rancher, for example: bash check-cve-2026-41053.sh cattle-system rancher. It needs read access to the Rancher deployment in the target namespace; no node shell or root access is required.

#!/usr/bin/env bash
# check-cve-2026-41053.sh
# Quick version gate for CVE-2026-41053 in Rancher Manager.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

NS="${1:-cattle-system}"
DEPLOY="${2:-rancher}"

fail_unknown() {
  echo "UNKNOWN: $1"
  exit 2
}

version_lt() {
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ] && [ "$1" != "$2" ]
}

version_ge() {
  ! version_lt "$1" "$2"
}

normalize_version() {
  echo "$1" | sed -E 's#^.*/##; s/^v//; s/@sha256:.*$//; s/-.*$//; s/[^0-9.].*$//'
}

is_affected() {
  local v="$1"
  if version_ge "$v" "2.13.0" && version_lt "$v" "2.13.6"; then
    return 0
  fi
  if version_ge "$v" "2.14.0" && version_lt "$v" "2.14.2"; then
    return 0
  fi
  return 1
}

command -v kubectl >/dev/null 2>&1 || fail_unknown "kubectl not found"

IMAGE="$(kubectl -n "$NS" get deploy "$DEPLOY" -o jsonpath='{.spec.template.spec.containers[0].image}' 2>/dev/null)"
[ -n "$IMAGE" ] || fail_unknown "could not read deployment $DEPLOY in namespace $NS"

RAW_TAG="${IMAGE##*:}"
VERSION="$(normalize_version "$RAW_TAG")"
[ -n "$VERSION" ] || fail_unknown "could not parse Rancher version from image: $IMAGE"

if is_affected "$VERSION"; then
  echo "VULNERABLE: Rancher version $VERSION falls in affected ranges (2.13.0-2.13.5 or 2.14.0-2.14.1). CVE reachability still depends on GitHub App auth being enabled."
  exit 1
fi

echo "PATCHED: Rancher version $VERSION is outside the affected ranges for CVE-2026-41053."
exit 0

Sources

1. GitHub Security Advisory GHSA-4j6x-2764-m8gh
2. SUSE CVE page for CVE-2026-41053
3. Rancher Security Advisories and CVEs
4. Rancher v2.14.2 release notes
5. Rancher v2.13.6 release notes
6. Configure GitHub App in Rancher
7. CISA Known Exploited Vulnerabilities Catalog