Red Hat has disclosed CVE-2026-66794, a high-impact server-side request forgery (SSRF) vulnerability affecting the cluster-proxy-addon component in Multicluster Engine for Kubernetes.
Published on August 19, 2026, the vulnerability carries a CVSS v3.1 score of 9.3 and could allow unauthenticated remote attackers to access services that are intended to remain isolated within connected managed Kubernetes clusters.
The issue is tracked as CWE-918 and results from insufficient authentication and authorization protections on a user-facing cluster-proxy route.
Red Hat Kubernetes SSRF Flaw
The affected component is designed to relay traffic between externally accessible endpoints and services operating inside managed clusters.
However, weaknesses in the route handling allow an attacker who can reach the exposed endpoint to manipulate URL path segments and potentially force the proxy to send requests to arbitrary internal services.
This effectively turns the cluster proxy into an SSRF primitive, allowing an attacker to use a trusted infrastructure component as an intermediary for reaching resources that should not be directly accessible from the internet.
The security implications are significant because Kubernetes environments frequently depend on network segmentation, firewall policies, private service endpoints, and internal routing controls to protect management interfaces and workloads.
An SSRF vulnerability can undermine those assumptions by causing requests to originate from infrastructure that already has network access to protected services.
Consequently, an attacker may not need direct connectivity to an internal dashboard, API, or workload if the vulnerable proxy can reach it on their behalf.
Red Hat identified multicluster-engine/cluster-proxy-addon-rhel9 and multicluster-engine/cluster-proxy-rhel9 as affected components.
At the time of disclosure, the advisory did not list security errata for either package. Organizations should therefore carefully review the affected product versions and vendor guidance before assuming that an installed package is protected.
Earlier packages within applicable minor-version streams should be treated as potentially vulnerable unless Red Hat explicitly identifies them as unaffected.
The CVSS vector for CVE-2026-66794 is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N. The rating indicates that exploitation can occur remotely over a network, requires low attack complexity, does not require authentication or user interaction, and crosses a security boundary.
The vulnerability initially received a more severe assessment from Red Hat, but the vendor subsequently revised its classification after determining that the issue enables unauthenticated SSRF rather than direct remote code execution. It is therefore classified as Important despite its 9.3 CVSS score.
The practical impact depends heavily on which internal services are reachable through the affected proxy and how those services enforce access controls.
Potential targets could include internal API endpoints, administrative dashboards, monitoring services, or other applications that rely primarily on network isolation.
Attackers could use SSRF to retrieve information, enumerate internal services, identify infrastructure components, or interact with endpoints that expose sensitive functionality.
Services implementing independent authentication and authorization controls provide an additional security barrier, although successful requests may still disclose valuable infrastructure information.
Organizations using Multicluster Engine for Kubernetes should immediately determine whether affected cluster-proxy routes are externally reachable.
Security teams should review ingress controllers, load balancers, firewall rules, and management-plane configurations to identify unnecessary exposure. Proxy and web-access logs should also be examined for unusual URL paths, unexpected destinations, internal IP addresses, and suspicious request patterns that could indicate SSRF exploitation.
CVE-2026-66794 demonstrates how a seemingly narrow proxy authorization weakness can become a significant security concern in multicluster Kubernetes environments.
Because cluster proxies can provide connectivity across security boundaries, protecting these interfaces requires strong authentication, strict authorization, hardened routing, network segmentation, and continuous monitoring.
Until affected deployments are confirmed secure, organizations should minimize external exposure and ensure that internal services do not depend solely on network isolation for protection.
No Comment! Be the first one.