A flaw was found in the multicloud-operators-subscription component.

CVE-2026-66792 is an incorrect-authorization flaw in the multicloud-operators-subscription component of Red Hat Advanced Cluster Management for Kubernetes (RHACM). The IsClusterAdmin() function trusts two user-settable annotations — apps.open-cluster-management.io/hosting-subscription (any non-empty value) and apps.open-cluster-management.io/cluster-admin: true — without verifying the caller actually holds the subscription-admin ClusterRole. Any user on a managed (spoke) cluster who can create a Subscription CR can add these annotations and gain multi-namespace deployment capability through the controller's privileged ServiceAccount. This affects all currently supported RHACM versions; no patch or vendor-approved mitigation exists as of 2026-08-20.

The vendor's CRITICAL / 9.9 rating is justified and, if anything, slightly generous on the AC dimension but directionally correct. The Scope: Changed designation accurately reflects that a spoke-cluster user crosses the trust boundary into hub-level cluster-admin authority. The PR:L rating is fair — Kubernetes RBAC commonly grants developers permission to create CRs in their namespaces. The only friction is that the target must be running RHACM with the Application Subscription addon enabled, which is the default. Because RHACM's entire purpose is fleet orchestration, landing cluster-admin on the hub means control over every managed cluster in the fleet — a blast radius that warrants the top severity bucket.

Why this verdict

• Trivial exploitation: The entire attack is two annotation key-value pairs on a Subscription CR. No memory corruption, no race condition, no special tooling — kubectl apply is the weapon. This is as close to zero-friction as privilege escalation gets.
• Role multiplier — fleet orchestration platform: RHACM's hub cluster is the control plane for all managed clusters. Cluster-admin on the hub is not single-host impact; it is fleet compromise by design. RHACM exists to propagate configuration to spoke clusters, so lateral movement is a built-in feature the attacker inherits. ≥90% of RHACM hub clusters occupy the high-value orchestration role — this is the canonical deployment.
• No patch, no vendor-approved mitigation: Red Hat explicitly states no mitigation meets their product-security criteria. Defenders are operating in a zero-day window with a trivially exploitable bug in a fleet-admin component.
• Scope: Changed is accurate: The attacker starts as a spoke-cluster namespace user and ends as hub cluster-admin — a clear trust-boundary crossing that the CVSS S:C designation correctly captures.
• Default configuration is vulnerable: The Application Subscription addon is enabled by default, and the controller's ServiceAccount ships with wildcard RBAC permissions. No hardening is required for exploitation; hardening is required to *prevent* it.

Why not higher?

The CVSS ceiling is 10.0, which requires AV:N/AC:L/PR:N (no authentication). This vulnerability requires PR:L — valid Kubernetes credentials on a managed cluster — which is a meaningful gate. The 9.5 reassessed score reflects a minor haircut from 9.9 to account for the authentication requirement, which eliminates unauthenticated internet-facing attack scenarios.

Why not lower?

Downgrading past CRITICAL would require evidence that the blast radius is contained to a single host or tenant. It is not — RHACM is definitionally a multi-cluster orchestration plane, and hub cluster-admin grants control over every spoke cluster. The authentication requirement (PR:L) is not a meaningful friction point: in RHACM environments, hundreds of developers and operators hold spoke-cluster credentials as part of normal operations. Additionally, there is no patch and no approved mitigation, meaning every RHACM deployment is currently exposed.

1. Deploy OPA Gatekeeper or Kyverno policy to block the admin annotations — Create a validating admission webhook that rejects any Subscription CR containing apps.open-cluster-management.io/cluster-admin: "true" or apps.open-cluster-management.io/hosting-subscription annotations unless the submitter is in an explicitly allowed group. This is the most direct control and should be deployed within 3 days per noisgate mitigation SLA for CRITICAL.
2. Restrict Subscription CR creation via RBAC — Remove create and update verbs on subscriptions.apps.open-cluster-management.io from all ClusterRoles except a dedicated subscription-admin role. Audit existing RoleBindings and ClusterRoleBindings. Deploy within 3 days.
3. Apply least-privilege ServiceAccount RBAC from CVE-2026-72508 mitigation — Apply the addon/manifests/permission/role.yaml to strip wildcard permissions from the application-manager ServiceAccount. This limits the blast radius even if the annotation bypass is exploited. Note: this must be re-applied after any ACM operator upgrade or pod restart. Deploy within 3 days.
4. Enable and alert on Kubernetes audit logs for ClusterRoleBinding creation — Configure your SIEM to alert on any ClusterRoleBinding create/update events where the actor is the subscription controller's ServiceAccount. This provides detection-in-depth while waiting for a patch.
5. Network-segment hub from untrusted spoke clusters — If feasible, restrict which spoke clusters can reach the hub API server. This limits the population of potential attackers to trusted cluster operators only.

Run this script on the RHACM hub cluster as a user with cluster-reader or equivalent permissions. It checks whether the IsClusterAdmin() annotation bypass is exploitable by verifying the subscription controller deployment exists and whether any admission policy blocks the dangerous annotations. Example: bash check_cve_2026_66792.sh

#!/usr/bin/env bash
# check_cve_2026_66792.sh
# Checks for CVE-2026-66792: IsClusterAdmin() annotation bypass in multicloud-operators-subscription
# Run on the RHACM hub cluster with cluster-reader permissions.
# Exit codes: 0 = VULNERABLE, 1 = PATCHED, 2 = UNKNOWN

set -euo pipefail

VULNERABLE=0
PATCHED=0
UNKNOWN=0

echo "[*] Checking for multicloud-operators-subscription controller..."
if ! kubectl get deployment -A -l component=multicloud-operators-subscription -o name 2>/dev/null | grep -q deployment; then
  # Try alternate label selectors
  if ! kubectl get deployment -A 2>/dev/null | grep -q 'multicloud-operators-subscription\|application-manager'; then
    echo "[*] multicloud-operators-subscription controller not found."
    echo "UNKNOWN - RHACM Application Subscription addon may not be installed."
    exit 2
  fi
fi
echo "[!] multicloud-operators-subscription controller IS deployed."

# Check for admission webhook policies blocking the annotations
echo "[*] Checking for validating admission webhooks that block admin annotations..."
BLOCKED=false
for webhook in $(kubectl get validatingwebhookconfigurations -o name 2>/dev/null); do
  rules=$(kubectl get "$webhook" -o json 2>/dev/null)
  if echo "$rules" | grep -qi 'cluster-admin\|hosting-subscription' 2>/dev/null; then
    echo "[+] Found admission policy that may block dangerous annotations: $webhook"
    BLOCKED=true
  fi
done

# Check for Gatekeeper constraints
if kubectl api-resources 2>/dev/null | grep -q constraints.gatekeeper.sh; then
  echo "[*] OPA Gatekeeper detected, checking constraints..."
  for constraint in $(kubectl get constraints -A -o name 2>/dev/null); do
    spec=$(kubectl get "$constraint" -o json 2>/dev/null)
    if echo "$spec" | grep -qi 'cluster-admin\|hosting-subscription' 2>/dev/null; then
      echo "[+] Found Gatekeeper constraint blocking admin annotations: $constraint"
      BLOCKED=true
    fi
  done
fi

# Check for Kyverno policies
if kubectl api-resources 2>/dev/null | grep -q kyverno.io; then
  echo "[*] Kyverno detected, checking policies..."
  for policy in $(kubectl get clusterpolicy -o name 2>/dev/null); do
    spec=$(kubectl get "$policy" -o json 2>/dev/null)
    if echo "$spec" | grep -qi 'cluster-admin\|hosting-subscription' 2>/dev/null; then
      echo "[+] Found Kyverno policy blocking admin annotations: $policy"
      BLOCKED=true
    fi
  done
fi

# Check if the ServiceAccount has wildcard RBAC (CVE-2026-72508 mitigation)
echo "[*] Checking application-manager ServiceAccount RBAC..."
SA_ROLES=$(kubectl get clusterrolebinding -o json 2>/dev/null | \
  python3 -c "
import json,sys
data=json.load(sys.stdin)
for item in data.get('items',[]):
  subjects = item.get('subjects',[])
  for s in subjects:
    if 'application-manager' in s.get('name',''):
      print(item['roleRef']['name'])
" 2>/dev/null || true)

WILDCARD=false
for role in $SA_ROLES; do
  rules=$(kubectl get clusterrole "$role" -o json 2>/dev/null || true)
  if echo "$rules" | grep -q '"\*"' 2>/dev/null; then
    echo "[!] ServiceAccount bound to ClusterRole '$role' with wildcard permissions."
    WILDCARD=true
  fi
done

echo ""
echo "========================================"
if [ "$BLOCKED" = true ]; then
  echo "PATCHED - Admission policy detected that blocks admin annotation bypass."
  exit 1
elif [ "$WILDCARD" = true ]; then
  echo "VULNERABLE - Controller is deployed with wildcard RBAC and no admission policy blocks the annotation bypass."
  exit 0
else
  echo "VULNERABLE - Controller is deployed and no admission policy blocks the annotation bypass. ServiceAccount RBAC could not be fully verified."
  exit 0
fi

Sources

1. Red Hat CVE Advisory — CVE-2026-66792
2. Red Hat Bugzilla #2507537
3. THREATINT CVE-2026-66792 Record
4. Red Hat CVE Advisory — CVE-2026-72508 (wildcard RBAC)
5. Red Hat CVE Advisory — CVE-2026-10090 (Helm confused deputy)
6. CyberSecurityNews — RHACM Privilege Escalation
7. GBHackers — Red Hat Kubernetes Privilege Escalation
8. Upstream multicloud-operators-subscription Repository