SURIQ
Red Hat disclosed two flaws in its cluster-management stack a day apart. The first needed a logged-in user. This one does not. CVE-2026-66794 lets an attacker with no account, holding nothing but a network path to a public web address, bypass authentication and push requests through to internal services on any cluster the hub manages. Red Hat rates it 9.3 on the CVSS scale and calls it critical. No fixed build has shipped, so the defense today is to keep untrusted networks away from that address.
The affected component is cluster-proxy-addon in Red Hat Multicluster Engine for Kubernetes, the fleet engine that Red Hat Advanced Cluster Management is built on. Its job is to tunnel requests from the central hub out to the clusters it governs. When the front door to that tunnel stops checking who is knocking, the tunnel becomes an open path to everything behind it.
What the flaw actually does
The cluster-proxy add-on publishes a user-facing route, a public web address, on the hub. Per Red Hat's bug report, that route terminates TLS in reencrypt mode with no client-certificate requirement and no authenticating proxy sitting in front of it, and the request handler behind it performs no authentication of its own. The destination the proxy forwards to is built from URL path segments that the caller controls, and those segments are not checked against an allowlist of permitted targets. So an outside caller can shape the path to name an internal service and have the hub go fetch it on their behalf.
That is a textbook server-side request forgery, where a trusted server is tricked into making requests an attacker chooses. Red Hat classifies it as CWE-918 and scores the confidentiality impact as high with a changed scope, which means the blast radius reaches past the flawed component into the services around it. By Red Hat's account, the payoff is reach into services that were never meant to answer an outside caller, which opens the door to reading data the attacker should not see and to deeper moves against the fleet. Put plainly: the hub turns into a proxy an unauthenticated outsider can aim at the private guts of every cluster it runs.
How it differs from the sibling flaw
| Detail | CVE-2026-66793 (a day earlier) | CVE-2026-66794 (today) |
|---|---|---|
| Login required | Yes, an authenticated hub user with annotate rights | No, unauthenticated |
| Entry point | Annotate a policy add-on object on the hub | Reach the public cluster-proxy route |
| What the attacker gets | Runs a chosen container as cluster-admin on a managed cluster | Proxies to internal services on any managed cluster |
| CVSS base score | 8.8 | 9.3 |
| Fix status | Errata pending | No fix yet, mitigation only |
The two deserve separate handling because the fix priority is not the same. The escalation flaw Red Hat disclosed a day earlier only bites when an untrusted user already holds a specific permission on the hub, so a single-admin setup is largely insulated. CVE-2026-66794 asks for nothing but a network path to the route. If that address is reachable from the internet or a broad internal segment, the precondition collapses to "can send it traffic," and that describes a much wider set of deployments.
Who is actually exposed
Operators of Red Hat Multicluster Engine, and therefore of Advanced Cluster Management, which ships it, where the cluster-proxy add-on's user-facing route is reachable from networks you do not control. The exposure is not about who your users are; it is about where that route lives. A hub whose proxy route is published to the internet, or to a flat corporate network that untrusted parties can touch, is exposed. A hub whose route is confined to a tightly held management segment is much less so. Because the proxy is the hub-to-managed-cluster tunnel, reaching it once means reaching services across the whole fleet, not a single cluster. That is what turns a mid-severity proxy bug into a 9.3.
Exploitation status
As of publication there is no public proof-of-concept, the flaw is not in CISA's Known Exploited Vulnerabilities catalog, and Red Hat reports no known exploitation in the wild. Red Hat made the CVE record public on August 19, 2026, after a private report on July 27. The tracking bug is still open with no fixed version attached, so the authoritative details come from Red Hat's own advisory rather than aggregators. Treat this as an open window rather than a live incident, but do not let the calm reading slow you down. The mechanism is simple once described, and unlike its sibling, there is no patch to reach for.
There is no patch yet, so lock down the route now
Red Hat's guidance is to restrict network access to the cluster-proxy add-on's user-facing route to trusted networks only, and to firewall the port that route listens on so only trusted sources can open a connection to it. That control closes the path no matter when a fixed build reaches your channel. Concretely:
- Cut the route off from untrusted networks. Confirm exactly which networks can reach the cluster-proxy route today. If it is exposed to the internet or a broad internal segment, put it behind firewall rules or network policy so only your management plane can reach it.
- Force authentication in front of it. Where you cannot fully isolate the route, place an authenticating reverse proxy or mutual TLS in front of it so an unauthenticated request never reaches the handler. The flaw is the missing check; supply one at the edge until Red Hat supplies one in the code.
- Watch the route's access logs. Requests whose path segments encode internal service hostnames, or that resolve to services never meant to be proxied from outside, are the signal here. An unauthenticated caller reaching a managed-cluster service through this route is not normal traffic.
- Track the advisory for the fix. Watch Red Hat's CVE page for the errata that patches your version, and apply it as soon as it lands. The network controls buy you time; the fix is the durable answer.
The pattern: the hub is the fleet's soft center
This is the third time in recent weeks that the seam between a control plane and the clusters it manages has been where the sharp edge lives. We covered the annotate-to-admin escalation a day ago, and back in July a missing certificate check in OpenShift hosted control planes let an outsider join a cluster's private tunnel, with Advanced Cluster Management among the affected products there too. The recurring lesson is that exposed management surfaces are the prize: we made the same point when an internet-reachable Ray dashboard turned into remote code execution. As more teams centralize fleet management, the hub becomes the highest-value target on the network. Model its public routes as if the internet can reach them, because for this flaw, that is all it takes.