← Back to Feed CACHED · 2026-09-27 03:13:51 · CACHE_KEY CVE-2026-41053
CVE-2026-41053 · CWE-303 · Disclosed 2026-06-30

Incorrect authentication caching in the team member ship expansion of the Rancher Github authentication…

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Rancher GitHub App auth hands every org team's RBAC to any single-team member on login"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Attacker holds GitHub org membership

The attacker has a legitimate GitHub account that belongs to at least one team in the target GitHub organization. This is the PR:L prerequisite — the attacker is an insider or has compromised an insider's GitHub credentials. No special permissions on the team are required; read-only membership in a trivial team like docs-contributors suffices.
Conditions required:
  • Valid GitHub account
  • Membership in ≥1 team in the target GitHub organization
Where this breaks in practice:
  • Requires insider access or credential compromise of an org member
  • GitHub organizations with strict membership governance reduce the pool of potential attackers
Detection/coverage: GitHub audit log captures org membership grants; Rancher auth logs show provider-type at login
STEP 02

Rancher configured with GitHub App auth + team RBAC mappings

The target Rancher instance uses the GitHub App authentication provider (not the older GitHub OAuth provider) and has mapped one or more GitHub teams to Rancher RBAC roles — cluster-owner, project-member, or custom roles. Without team-based RBAC bindings, the inflated principals have no downstream effect.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Rancher API: GET /v3/authConfigs reveals active provider type; GET /v3/clusterRoleTemplateBindings reveals team-principal bindings
STEP 03

Attacker authenticates to Rancher

The attacker logs in through the Rancher UI or API using the GitHub App flow. This is a normal login — no exploit code, no crafted request, no timing attack. The vulnerability triggers server-side during the standard authentication pipeline.
Conditions required:
  • Network access to Rancher UI/API (typically HTTPS on port 443)
Where this breaks in practice:
  • Rancher behind VPN or private network reduces exposure
  • MFA on GitHub account adds friction to credential-compromise scenarios
Detection/coverage: Rancher audit log records successful authentication events with user principal
STEP 04

Rancher expands all org teams into user's principals

The authentication caching code iterates over every team defined in the GitHub organization rather than the user's actual team list. The user's session is stamped with group principals for all teams — github_team://org/team-a, github_team://org/team-b, etc. — regardless of actual membership. No error is logged; the expansion appears normal.
Conditions required:
  • Vulnerable Rancher version processing the login
Where this breaks in practice:
  • None — this is the bug itself; it fires deterministically on every login through the affected provider
Detection/coverage: Compare stored user principals (GET /v3/principals) against GitHub API team membership (GET /orgs/{org}/teams/{team}/members) — mismatch reveals inflation
STEP 05

Attacker inherits all team-mapped RBAC permissions

Downstream authorization checks honor the phantom group principals. The attacker now has every permission mapped to every team in the org: cluster-admin on production clusters, project-owner on sensitive namespaces, access to secrets, workloads, and Helm releases. The escalation is silent — no failed-authz events, no permission-denied logs.
Conditions required:
  • Teams mapped to meaningful RBAC roles (cluster-owner, project-admin, etc.)
Where this breaks in practice:
  • Organizations that use minimal team-to-role mappings limit blast radius
  • Namespace-level network policies may limit lateral movement within clusters
Detection/coverage: Rancher audit log shows the user accessing resources outside their legitimate team scope; Kubernetes audit logs show unexpected RBAC bindings
03 · Compensating Control

1
HIGH 7.5→IGNORE 0.0
SEVERITY REDUCED
Switch from GitHub App to GitHub OAuth auth provider — The vulnerability only affects the GitHub App provider, not the older GitHub OAuth provider. Switching auth backends immediately eliminates the attack surface. This is the most effective compensating control short of patching. Deploy within the noisgate mitigation SLA of 30 days for HIGH severity. Rancher docs provide a migration path under Authentication Configuration.
2
HIGH 7.5→LOW 2.0
SEVERITY REDUCED
Remove team-level RBAC bindings; use org-level only — If team-to-role mappings are removed from Rancher's RBAC configuration, the inflated team principals have no downstream authorization effect. Only org-level principals (which are correctly scoped) drive access. This eliminates the privilege-escalation impact while keeping GitHub App auth active. Deploy within 30 days.
3
HIGH 7.5→HIGH 6.5
Audit and prune stored user principals — Query 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.
4
HIGH 7.5→MEDIUM 5.5
SEVERITY REDUCED
Restrict Rancher network exposure to VPN/internal only — Placing the Rancher UI/API behind a VPN or zero-trust gateway limits the attacker's ability to reach the login page. This reduces AV from Network to Adjacent, but does not prevent exploitation by legitimate VPN users who are also GitHub org members. Deploy within 30 days.
5
HIGH 7.5→IGNORE 0.0
SEVERITY REDUCED
Upgrade to Rancher 2.13.6 or 2.14.2 — The definitive fix. Patches correct the team iteration logic and force a startup migration that refreshes all cached user principals. This is the remediation action. Deploy within the noisgate remediation SLA of 180 days for HIGH severity. Post-upgrade, verify the principal refresh migration completed successfully.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNo 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 availabilityNone 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 score0.00524 (0.524%) — indicates low predicted exploitation probability in the next 30 days. Roughly 40th–50th percentile across all scored CVEs.
KEV statusNot listed. No CISA Known Exploited Vulnerabilities entry as of 2026-09-27.
CVSS vector interpretationCVSS: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 versionsRancher 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 versionsv2.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 surfaceRancher 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 timelinePatches 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.
ReporterNot publicly credited in the GHSA advisory or OSV record. SUSE internal security contact ([email protected]) listed as CNA contact.

Sources.

  1. GitHub Security Advisory (GHSA-4j6x-2764-m8gh)
  2. OSV — CVE-2026-41053
  3. NVD — CVE-2026-41053
  4. bex.co — Rancher CVE-2026-41053 GitHub Team RBAC Escalation Analysis
  5. SUSE Rancher Security Advisories
  6. OpenCVE — CVE-2026-41053
  7. Rancher GitHub App Auth Configuration Docs
05 · The Call

Final Verdict
= UNCHANGED to HIGH (7.5/10)

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.

06 · Verification

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

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously