SUSE Rancher Manager Project Owner PSA bypass enabling privileged workloads

CVE-2026-41052 affects SUSE Rancher Manager and lets a user with the built-in Project Owner role change Pod Security Admission settings on namespaces inside their project, then deploy privileged workloads that Rancher policy was supposed to block. Per the Rancher advisory, affected ranges are >=2.14.0,<2.14.2, >=2.13.0,<2.13.6, and >=2.12.0,<2.12.10; fixed releases are 2.14.2, 2.13.6, and 2.12.10.

GitHub/SUSE scored it High 8.4 on May 27, 2026, but that is too hot for enterprise patch triage. This is not an unauthenticated internet bug; it is a post-auth, role-bound authorization flaw that mainly matters in multi-tenant Rancher environments where you rely on PSA to keep semi-trusted project owners from running privileged containers.

Why this verdict

• Post-auth and role-bound: attacker needs valid Rancher access plus the built-in Project Owner role before the bug matters
• Shared-cluster dependent: the risk is materially higher only where you rely on PSA to constrain semi-trusted tenants inside the same cluster
• Impact is real once reached: privileged workload deployment can cross from project admin into host/cluster-level consequences

Why not higher?

This is not unauthenticated remote code execution, not a pre-auth admin-console takeover, and not a bug every internet scanner can weaponize at scale. The prerequisite chain compounds hard: valid account, correct cluster role, project ownership, namespace control, and a deployment model where PSA is the control boundary.

Why not lower?

Once the path is available, the attacker is not just changing metadata; they can authorize privileged containers that may reach host resources and enable cluster escalation. In organizations using Rancher for multi-tenant guardrails, that is a meaningful security boundary failure and deserves more than backlog-only treatment.

1. Replace the built-in role path — If you cannot patch immediately, create a custom Project Owner-like role that removes unrestricted project-resource wildcard behavior and does not grant updatepsa. For a MEDIUM noisgate verdict there is no mitigation SLA, but do this immediately on shared clusters because it cuts off the only documented abuse path.
2. Alert on PSA downgrades — Monitor namespace label changes to pod-security.kubernetes.io/*, especially moves toward privileged. There is no mitigation SLA for MEDIUM, but this control gives you near-term visibility while you work through the remediation window.
3. Block privileged pod specs elsewhere — Use admission policy or runtime controls outside Rancher's built-in role model to deny privileged containers, host PID/IPC, hostPath, and similar high-risk settings. There is no mitigation SLA for MEDIUM, but this adds a second enforcement layer if PSA becomes tenant-editable.
4. Tighten Project Owner assignment — Treat Project Owner as a high-trust role in shared clusters and review who actually needs it. There is no mitigation SLA for MEDIUM, but reducing role sprawl directly shrinks the exploitable population.

Run this from an auditor workstation or admin jump box that already has kubectl pointed at the management cluster hosting Rancher. Invoke it as bash check_cve_2026_41052.sh cattle-system; it needs read access to the rancher deployment in that namespace and outputs VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# check_cve_2026_41052.sh
# Detects whether the Rancher Manager version is in an affected range for CVE-2026-41052.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

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

have_cmd() {
  command -v "$1" >/dev/null 2>&1
}

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

ver_ge() {
  ! ver_lt "$1" "$2"
}

normalize() {
  local v="$1"
  v="${v##*:}"
  v="${v#v}"
  echo "$v"
}

if ! have_cmd kubectl; then
  echo "UNKNOWN: kubectl not found"
  exit 2
fi

image="$(kubectl -n "$NS" get deploy "$DEPLOY" -o jsonpath='{.spec.template.spec.containers[0].image}' 2>/dev/null || true)"
if [ -z "$image" ]; then
  echo "UNKNOWN: unable to read deployment $DEPLOY in namespace $NS"
  exit 2
fi

version="$(normalize "$image")"
if [ -z "$version" ]; then
  echo "UNKNOWN: could not parse Rancher image tag from '$image'"
  exit 2
fi

branch="$(echo "$version" | awk -F. '{print $1"."$2}')"

case "$branch" in
  2.14)
    if ver_ge "$version" "2.14.0" && ver_lt "$version" "2.14.2"; then
      echo "VULNERABLE: Rancher $version matches >=2.14.0,<2.14.2"
      exit 1
    elif ver_ge "$version" "2.14.2"; then
      echo "PATCHED: Rancher $version is >=2.14.2"
      exit 0
    fi
    ;;
  2.13)
    if ver_ge "$version" "2.13.0" && ver_lt "$version" "2.13.6"; then
      echo "VULNERABLE: Rancher $version matches >=2.13.0,<2.13.6"
      exit 1
    elif ver_ge "$version" "2.13.6"; then
      echo "PATCHED: Rancher $version is >=2.13.6"
      exit 0
    fi
    ;;
  2.12)
    if ver_ge "$version" "2.12.0" && ver_lt "$version" "2.12.10"; then
      echo "VULNERABLE: Rancher $version matches >=2.12.0,<2.12.10"
      exit 1
    elif ver_ge "$version" "2.12.10"; then
      echo "PATCHED: Rancher $version is >=2.12.10"
      exit 0
    fi
    ;;
  *)
    echo "UNKNOWN: Rancher $version is outside the advisory's documented affected branches (2.12/2.13/2.14)"
    exit 2
    ;;
esac

echo "UNKNOWN: unable to classify Rancher version $version"
exit 2

Sources

1. Rancher GitHub advisory GHSA-vx8h-4prv-g744
2. SUSE Rancher Manager v2.14 Security Advisories and CVEs
3. SUSE Rancher Manager v2.12 Security Advisories and CVEs
4. SUSE Rancher Manager v2.14.2 release notes
5. SUSE Rancher Manager v2.12.10 release notes
6. Kubernetes Pod Security Standards
7. CISA Known Exploited Vulnerabilities Catalog
8. Rancher releases