CVE-2026-66794: Critical Auth Bypass in Red Hat Multicluster Engine cluster-proxy-addon — Detection and Remediation Guide

NVD has published CVE-2026-66794, a CVSS 9.3 (Critical) vulnerability in the cluster-proxy-addon component of Red Hat Multicluster Engine for Kubernetes (MCE). This is a network-exploitable, unauthenticated authentication and authorization bypass: any attacker who can reach the user-facing route of the cluster-proxy service can manipulate URL path segments to proxy arbitrary requests into services running on any managed cluster attached to the hub.

For defenders, the implication is severe. Multicluster Engine is the control plane that organizations — particularly those running Red Hat Advanced Cluster Management (ACM) or OpenShift fleets — use to manage dozens or hundreds of downstream clusters. A bypass at this layer is not a single-cluster problem; it is a skeleton key into every managed environment, including internal APIs, control-plane-adjacent services, and workloads that were never intended to be reachable from the network edge. Because exploitation requires no credentials and no user interaction, this vulnerability belongs at the top of your remediation queue, ahead of nearly everything else currently open in your Kubernetes estate.

This post breaks down how the flaw works, what exploitation looks like in your telemetry, and exactly what to do about it — including detection content you can deploy today.

Technical Analysis

Affected Component and Products

• Component: cluster-proxy-addon — the addon deployed by Multicluster Engine that provides a user-facing proxy route into managed clusters, typically used so administrators can reach managed cluster APIs and services through the hub.
• Products: Red Hat Multicluster Engine for Kubernetes (MCE), and by extension deployments of Red Hat Advanced Cluster Management for Kubernetes, which bundles MCE as its foundational operator.
• Exposure: Any hub cluster where the cluster-proxy user-facing route (an OpenShift Route or equivalent ingress) is reachable by an untrusted network. If your hub cluster's routes are internet-accessible, treat this as internet-exploitable.

Vulnerability Details

How the Attack Works — Defender's View

The cluster-proxy-addon exposes a route that is supposed to enforce two things before forwarding traffic: (1) that the requester is authenticated, and (2) that the requester is authorized to reach the specific service/cluster combination named in the request. The flaw sits in how the proxy parses and normalizes URL path segments.

By crafting path segments that the proxy's routing/authorization logic interprets differently than its upstream forwarder does — a classic path parsing discrepancy — an unauthenticated attacker can cause the proxy to forward requests to arbitrary services in any managed cluster. The authorization decision is made against a path the attacker controls, while the actual proxied request goes somewhere else entirely.

The exploitation chain from a defender's perspective:

1. Recon: Attacker identifies the cluster-proxy route hostname (often predictable: routes follow the *.apps.<cluster-domain> pattern in OpenShift, and cluster-proxy addon routes have discoverable naming conventions).
2. Probe: Attacker sends requests with manipulated path segments — encoded traversal sequences, doubled slashes, or segment confusion — to observe which paths bypass the authentication challenge. Legitimate requests to the proxy without valid credentials should return 401/403; bypass responses return proxied content from internal services.
3. Access: Attacker proxies requests into internal services on managed clusters — Kubernetes APIs, application admin interfaces, metrics/debug endpoints (e.g., /metrics, /debug/pprof), or cloud metadata-adjacent services.
4. Pivot: Disclosed information (service account tokens, secrets listed via the API, internal topology) enables deeper compromise of the managed fleet.

Exploitation Status

As of publication, NVD lists CVE-2026-66794 as a published, network-exploitable critical. There is no confirmed in-the-wild exploitation reported in the source advisory yet, and it has not been added to the CISA Known Exploited Vulnerabilities catalog at time of writing. However: unauthenticated, network-reachable auth bypasses in multicluster control planes are exactly the class of bug that moves from disclosure to scanning within days. Do not wait for KEV listing. Internet-facing hub routes should be considered under active reconnaissance pressure now.

Why This Pattern Matters

Path normalization discrepancies between an auth-enforcing front end and a forwarding back end are a recurring, high-impact class — we have seen the same architectural failure produce criticals in ingress controllers, API gateways, and reverse proxies across 2025 and 2026. The defensive lesson generalizes: any proxy that makes an authorization decision on a URL it then transforms before forwarding is suspect. If you run custom proxies or gateway plugins with the same pattern, audit them with the same lens.

Detection & Response

The highest-fidelity detection surface for this vulnerability is the hub cluster's Kubernetes/OpenShift audit log and the ingress/router access logs, because every exploitation attempt traverses the cluster-proxy route with anomalous path segments. Endpoint detections are secondary but useful for post-exploitation behavior on managed clusters.

Sigma Rules

---
title: Kubernetes API Server Access to Sensitive Endpoints from Unauthenticated or Anonymous User
id: 3f7a2c91-8b4d-4e6a-9c15-2d8e7f1a5b60
status: experimental
description: Detects requests to Kubernetes API endpoints sensitive to the CVE-2026-66794 scenario where an unauthenticated or system:anonymous subject successfully retrieves secrets, service account tokens, or proxy-reachable resources. Successful (non-403) responses for anonymous subjects on these resources are high-fidelity indicators of an authorization bypass such as the cluster-proxy-addon path manipulation flaw.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-66794
  - https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/04/10
tags:
  - attack.credential_access
  - attack.t1552
logsource:
  product: kubernetes
  service: audit
detection:
  selection_user:
    user.username:
      - 'system:anonymous'
      - 'system:unauthenticated'
  selection_verb:
    verb:
      - 'get'
      - 'list'
      - 'proxy'
  selection_resource:
    objectRef.resource:
      - 'secrets'
      - 'serviceaccounts'
      - 'services'
  filter_denied:
    responseStatus.code:
      - 401
      - 403
  condition: selection_user and selection_verb and selection_resource and not filter_denied
falsepositives:
  - Misconfigured RBAC intentionally granting anonymous read access (should itself be remediated)
level: high
---
title: Suspicious Path Traversal Patterns in Kubernetes Service Proxy Requests
id: 8c1e5a47-2f93-4b7d-a618-9e3c4d2f7a01
status: experimental
description: Detects URL path segment manipulation patterns consistent with CVE-2026-66794 exploitation against the cluster-proxy-addon user-facing route, including encoded traversal, dot-segment confusion, and doubled slashes in request URIs observed in Kubernetes audit or ingress telemetry.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-66794
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/10
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  product: kubernetes
  service: audit
detection:
  selection:
    requestURI|contains:
      - '%2e%2e'
      - '%2E%2E'
      - '..%2f'
      - '%2f..'
      - '../'
      - '..\\'
      - '//api/'
      - '/./'
      - '%252e'
  condition: selection
falsepositives:
  - Rare legitimate API clients with unusual path construction; validate source IP and user agent
level: high
---
title: Process Execution from kubelet or Container Runtime Indicating Post-Exploitation Exec
id: 5b9d3e12-6a48-4f2c-b794-1e7a9c3d8f52
status: experimental
description: Detects interactive shells or reconnaissance tooling spawned via kubectl exec or API-driven container exec, a likely follow-on action after an attacker gains proxied access to managed cluster APIs via CVE-2026-66794.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-66794
  - https://attack.mitre.org/techniques/T1609/
author: Security Arsenal
date: 2026/04/10
tags:
  - attack.execution
  - attack.t1609
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/kubelet'
      - '/containerd'
      - '/cri-o'
      - '/runc'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/ash'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/kubectl'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate kubectl exec sessions by cluster administrators; correlate with authenticated user identity and change windows
level: medium

Tuning note: Rule one and two assume you are shipping Kubernetes/OpenShift API audit logs (and ideally router/ingress access logs) to your SIEM. If you are not auditing the hub cluster's API today, that gap is itself a finding — enable at least Metadata-level auditing with a policy that captures RequestResponse for secrets and proxy subresources.

KQL — Microsoft Sentinel / Defender

This query hunts for the path-manipulation pattern and unauthenticated success against proxy-sensitive resources, assuming Kubernetes audit events arrive via the KubeEvents/diagnostic ingestion or as Syslog/CEF. Adapt the table to your ingestion path — the Syslog variant covers the common Fluentd/Fluent Bit → Log Analytics pipeline used for OpenShift audit forwarding.

// Hunt: CVE-2026-66794 cluster-proxy-addon path manipulation and anonymous access
// Adjust table name to your audit ingestion path (Syslog shown; also check KubeEvents / ContainerLogV2)
let SuspiciousPathPatterns = dynamic(["%2e%2e", "%2E%2E", "..%2f", "%2f..", "../", "%252e", "/./", "//api/"]);
let SensitiveResources = dynamic(["secrets", "serviceaccounts", "proxy"]);
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("cluster-proxy", "multicluster", "proxy")
    or SyslogMessage has_any (SensitiveResources)
| extend ParsedMsg = tostring(SyslogMessage)
| extend IsPathTraversal = ParsedMsg has_any (SuspiciousPathPatterns)
| extend IsAnonymous = ParsedMsg has_any ("system:anonymous", "system:unauthenticated")
| extend ResponseCode = extract(@'"code":(\d{3})', 1, ParsedMsg)
| extend RequestURI = extract(@'"requestURI":"([^"]+)"', 1, ParsedMsg)
| extend SourceIP = extract(@'"sourceIPs":\["([^"]+)"\]', 1, ParsedMsg)
| where IsPathTraversal
    or (IsAnonymous and ResponseCode !in ("401", "403") and RequestURI has_any (SensitiveResources))
| project TimeGenerated, Computer, SourceIP, RequestURI, ResponseCode, IsPathTraversal, IsAnonymous, ParsedMsg
| order by TimeGenerated desc
// PIVOT: For any SourceIP with hits, expand the window and pull ALL of its requests for 48h around first-seen

For Defender for Endpoint visibility on managed cluster nodes (if MDE is deployed to your Linux nodes):

// Post-exploitation: interactive tooling spawned by container runtime on managed cluster nodes
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName in~ ("kubelet", "containerd", "cri-o", "runc")
| where FileName in~ ("sh", "bash", "dash", "curl", "wget", "nc", "ncat", "kubectl", "python", "python3")
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, AccountName
| order by TimeGenerated desc

Velociraptor VQL

For node-level hunting on managed cluster Linux nodes, this artifact surfaces shell/recon processes parented to the container runtime — the telltale of API-driven exec after a proxied intrusion.

-- Hunt: interactive shells and tooling spawned by container runtimes (post-exploitation exec)
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)^(sh|bash|dash|ash|curl|wget|nc|ncat|kubectl|python3?)$'
  AND (
    SELECT Name FROM pslist(pid=Pid)  -- placeholder comment: runtime parent check below
  ) OR CommandLine =~ '(?i)(/var/run/secrets|serviceaccount|token|KUBERNETES_SERVICE)'

A cleaner two-pass version that actually joins parent processes:

-- Correlate child processes against runtime parents (kubelet/containerd/cri-o/runc)
LET parents <= SELECT Pid, Name AS ParentName FROM pslist()
   WHERE Name =~ '(?i)(kubelet|containerd|cri-o|runc)'
SELECT p.Pid, p.Ppid, p.Name, p.CommandLine, p.Username, p.CreateTime, par.ParentName
FROM pslist() AS p
JOIN parents AS par ON p.Ppid = par.Pid
WHERE p.Name =~ '(?i)^(sh|bash|dash|curl|wget|nc|ncat|kubectl)$'

Remediation / Verification Script

Run the following from a shell with oc or kubectl access to the hub cluster. It identifies your MCE version, locates the cluster-proxy addon deployment and its exposed route, checks for evidence of path-manipulation in router logs, and — as an interim mitigation — restricts route access pending the operator upgrade.

#!/usr/bin/env bash
# CVE-2026-66794 - Multicluster Engine cluster-proxy-addon verification & interim hardening
set -euo pipefail

echo "=== [1] Identify Multicluster Engine version ==="
oc get mce -o jsonpath='{.items[*].spec.currentVersion}{"\n"}' 2>/dev/null || \
  kubectl get multiclusterengine -A -o jsonpath='{.items[*].spec.currentVersion}{"\n"}'

echo "=== [2] Locate cluster-proxy-addon deployments ==="
kubectl get deployments -A | grep -i cluster-proxy || echo "No cluster-proxy deployments found in this context"

echo "=== [3] Enumerate exposed routes for cluster-proxy (user-facing entry point) ==="
oc get routes -A 2>/dev/null | grep -i proxy || echo "No matching routes found"

echo "=== [4] Check ClusterProxy / ManagedProxyServiceResolver CRs (addon config surface) ==="
kubectl get clusterproxy -A 2>/dev/null || echo "clusterproxy CRD not present or no permission"

echo "=== [5] Hunt router/ingress logs for path-traversal patterns (last 24h) ==="
for ns in openshift-ingress router-default; do
  for pod in $(oc get pods -n "$ns" -o name 2>/dev/null | grep -i router || true); do
    echo "-- scanning $pod --"
    oc logs -n "$ns" "$pod" --since=24h 2>/dev/null | \
      grep -Ei '(%2e%2e|\.\.%2f|%2f\.\.|\.\./|%252e|//api/)' && \
      echo "!! Suspicious path segments observed in $pod — investigate source IPs" || true
  done
done

echo "=== [6] INTERIM MITIGATION: restrict route access by source IP allowlist ==="
# Replace <ROUTE_NAME> <ROUTE_NS> and the CIDR list with your admin networks.
# oc annotate route <ROUTE_NAME> -n <ROUTE_NS> \
#   haproxy.router.openshift.io/ip_whitelist="10.0.0.0/8 192.168.0.0/16" --overwrite

echo "=== [7] Confirm external exposure of hub routes ==="
oc get routes -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{" -> "}{.spec.host}{"\n"}{end}' 2>/dev/null | grep -i proxy

echo ""
echo "NEXT STEPS:"
echo "  1. Upgrade Multicluster Engine operator to the fixed release per the Red Hat advisory for CVE-2026-66794."
echo "  2. Apply the ip_whitelist annotation (step 6) as a compensating control until patched."
echo "  3. If step 5 fired, treat as incident: preserve logs, rotate service account tokens on managed clusters."

Remediation

1. Patch immediately. Upgrade the Multicluster Engine operator on every hub cluster to the fixed release identified in Red Hat's advisory for CVE-2026-66794. ACM customers receive the fix through the bundled MCE upgrade — verify the MCE operand version post-upgrade, not just the ACM subscription state. Track the authoritative record at NVD and the linked Red Hat security advisory for the exact fixed version applicable to your release stream.
2. Inventory your exposure. Enumerate every hub cluster running MCE or ACM. For each, determine whether the cluster-proxy user-facing route is reachable from the internet, partner networks, or flat internal segments. Any route reachable beyond your admin networks is priority one.
3. Compensating controls until patched. Apply source-IP allowlisting on the route (haproxy.router.openshift.io/ip_whitelist on OpenShift), front the route with a WAF rule blocking encoded path traversal sequences (%2e, ..%2f, double slashes), and if operationally feasible, temporarily disable the cluster-proxy addon (cluster-proxy in the MCE addon config) on hubs that do not depend on it.
4. Hunt before you patch. Deploy the Sigma/KQL content above against at least 30 days of retained hub-cluster audit and router logs. A critical unauthenticated bypass should be assumed probed; look for the path-segment patterns and anonymous successful responses before assuming a clean bill.
5. If exploitation is suspected: rotate all service account tokens on affected managed clusters, review RBAC bindings for drift, force re-issuance of any credentials reachable via proxied internal services, and treat managed-cluster secrets as potentially disclosed.
6. Structural hardening: enable RequestResponse-level audit logging for secrets and proxy subresources on hub clusters, segment hub cluster management networks from general user networks, and add path-normalization discrepancy testing to your gateway/proxy review checklist — this vulnerability class recurs.

Do not let the absence of confirmed in-the-wild exploitation become a reason to defer. A CVSS 9.3 unauthenticated bypass in multicluster management infrastructure is precisely the kind of finding that defines the difference between a patch window and an incident report.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub