SURIQ
Hosted control planes solve a real problem. Instead of dedicating machines to every OpenShift cluster's brain, you run that brain as pods inside a shared management cluster. For that to work, the control plane needs a way to reach back into each guest cluster's worker nodes, so it opens a network endpoint that those nodes dial into. CVE-2026-16242 is what happens when that endpoint forgets to check who is dialing.
Red Hat rates it 9.4 on the CVSS scale and marks it critical. An attacker needs no account, no user interaction, and only network reach to the endpoint. If you run guest clusters with hosted control planes, this is worth an hour of your morning.
What actually broke
OpenShift's hosted control planes, built on the HyperShift project, use a component called Konnectivity to carry traffic between the control plane and the worker nodes. A Konnectivity proxy-server sits with the control plane. Konnectivity agents run down in the node network and dial out to that server to build a tunnel. Almost everything the API server sends toward a node rides that tunnel: interactive shells opened with kubectl exec, log retrieval, the calls that reach each node's kubelet, and traffic bound for admission webhooks.
Agents are supposed to prove who they are with a client certificate signed by the cluster's own Konnectivity certificate authority. According to Red Hat's bug report, the listener that agents connect to came up with neither the --cluster-ca-cert setting nor token-based authentication configured, so it never asked a connecting client to prove itself. Anyone who can reach the endpoint can present an arbitrary certificate, a self-signed one, or none at all, and be accepted as an agent.
Once accepted, the attacker joins the routing pool and becomes one of the connectors the control plane hands node-bound traffic to. From there, Red Hat says, they can watch that traffic, tamper with it, or cut it off. The sensitive material a control plane pushes downward is all in reach: shell sessions opened through exec, the pod definitions a kubelet receives, the service account tokens workloads use to authenticate, and the contents of Secrets and config maps. It is a man in the middle wedged between a cluster's brain and its machines.
The CVE record scores it 9.4 and files the root cause under CWE-306, the weakness class for leaving a sensitive function with no authentication in front of it. The high confidentiality and integrity ratings track the reading and tampering; the lower availability rating reflects that a connector can also silently drop packets.
Who is exposed
Red Hat's record puts three of its products in scope: OpenShift Container Platform 4, the Multicluster Engine for Kubernetes, and Advanced Cluster Management 2, in each case where hosted control planes are in use. If you run guest clusters this way on any of them, this is yours to handle. Standard OpenShift, where the control plane runs on its own dedicated machines rather than as hosted pods, is not the subject of this flaw.
One design detail turns this from theory into real risk. The agent endpoint exists so that nodes, which can sit in a different network from the management cluster, can reach the control plane. In many hosted-control-plane topologies that endpoint is published through a load balancer or a route rather than kept on an internal segment. The more reachable it is, the more a missing authentication check matters. Map where yours actually answers from before you assume it is safely tucked away.
What to do before Red Hat ships the fix
Be honest about the timeline. The fix, openshift/hypershift pull request 9031 (tracked as OCPBUGS-99014), adds the missing --cluster-ca-cert so the proxy-server validates agent certificates against the certificate authority bundle that is already mounted in the container. At the time of writing that pull request is still open and no general errata has shipped, so there is no fixed version to upgrade to yet. That makes this a case where knowing your exposure beats waiting.
- Find out whether the agent endpoint is reachable from untrusted networks. If your hosted clusters publish Konnectivity through a load balancer or route, restrict who can reach it to the node networks that genuinely need it, using network policy, a firewall, or a cloud security group.
- Watch the proxy-server logs for agent connections you cannot account for. A rogue connector shows up as an extra agent registration: an agent identifier or source address that does not match your known node fleet, or a connection count higher than the number of nodes you run.
- Track the Red Hat advisory and apply the errata the moment it lands. The one-line fix is already written; the value now is closing the network gap until you can deploy it.
This is a CWE-306 bug of the plainest kind: the guardrail was present and nobody switched it on. The certificate authority bundle was already sitting in the container. The server simply was not told to check against it. That shape recurs across Kubernetes-adjacent proxies, where mutual TLS is available but a single missing flag turns an authenticated channel into an open door. We saw the same waiting-for-a-patch pressure with Argo CD's unauthenticated takeover, and the same control-plane exposure question with VMware's Avi load balancer flaws. Managed detection that reads control-plane logs, not just endpoint files, is what surfaces a rogue agent in the window before a patch exists.