EUVD-2026-45897
GHSA-43hh-68v6-mf36
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L
Remote unauthenticated agent join with no interaction (AV:N/AC:L/PR:N/UI:N); MITM of kube-apiserver-to-node traffic affects components beyond the proxy, so S:C, with C:H/I:H and partial A:L for traffic drops.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
Lifecycle Timeline
3DescriptionCVE.org
A flaw was found in the Konnectivity proxy-server configuration for hosted control planes. The agent-facing listener was started without --cluster-ca-cert (and without token-based agent authentication), so client certificates were not validated. A remote attacker who can reach the Konnectivity cluster endpoint could connect as an unauthenticated agent, join the routing pool, and potentially proxy, inspect, modify, or drop control-plane-to-node traffic.
AnalysisAI
Authentication bypass in Red Hat OpenShift HyperShift (hosted control planes) lets a network-reachable attacker impersonate a Konnectivity agent because the proxy-server's agent-facing listener was configured without --cluster-ca-cert and without token-based agent authentication, so client certificates go unvalidated. Any remote party who can reach the Konnectivity cluster endpoint can register as an unauthenticated agent, join the routing pool, and then proxy, inspect, modify, or drop control-plane-to-node traffic. No public exploit identified at time of analysis; the issue is corrected upstream in openshift/hypershift PR #9031 by adding the missing --cluster-ca-cert flag.
Technical ContextAI
Konnectivity is the Kubernetes network proxy that tunnels API-server-to-node (control-plane-to-worker) traffic; it consists of a proxy-server running alongside kube-apiserver and agents that dial in from the data-plane side. In HyperShift/hosted control planes the proxy-server runs as the 'konnectivity-server' container within the kube-apiserver deployment. The --cluster-ca-cert flag supplies the CA used to validate mTLS client certificates presented by connecting agents; without it (and with no token auth configured), the agent-facing listener accepts any TLS client, meaning agent identity is never verified. This maps to CWE-306 (Missing Authentication for Critical Function): a security-critical control channel was exposed with authentication effectively disabled. The upstream fix, confirmed by the PR diff, adds '--cluster-ca-cert /etc/konnectivity/ca/ca.crt' to the konnectivity-server args across all platform fixtures (AROSwift, GCP, IBMCloud, TechPreviewNoUpgrade, and the default/base), plus a regression test (TestKonnectivityServerAuthenticatesAgents) asserting the flag is present.
Affected ProductsAI
The affected product is Red Hat OpenShift hosted control planes implemented via HyperShift (openshift/hypershift), specifically deployments whose kube-apiserver-embedded konnectivity-server was rendered without the --cluster-ca-cert flag. The PR touches fixtures for multiple platforms (ARO/AROSwift, GCP, IBM Cloud, and TechPreviewNoUpgrade plus the default profile), indicating the misconfiguration spanned these managed/hosted platform variants. No exact vulnerable version range or CPE was provided in the input; affected builds should be identified via the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-16242 and the tracking bug at https://bugzilla.redhat.com/show_bug.cgi?id=2502690. The upstream code fix is at https://github.com/openshift/hypershift/pull/9031.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed - apply the Red Hat OpenShift update that includes openshift/hypershift PR #9031, which adds '--cluster-ca-cert /etc/konnectivity/ca/ca.crt' to the konnectivity-server container so agent client certificates are validated; track the fixed build via the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-16242 and Bugzilla 2502690. As an interim compensating control before patching, restrict network reachability of the Konnectivity agent-facing/cluster endpoint to only trusted agent sources using network policies, security groups, or firewall rules (trade-off: legitimate agents must be explicitly allow-listed, and misconfiguration can break control-plane-to-node connectivity), and verify each konnectivity-server container's args actually contain --cluster-ca-cert (or a token-auth equivalent) - deployments already carrying the flag are not exposed. Because the root cause is a missing authentication configuration rather than a code memory-safety bug, ensuring the flag is present and pointed at the correct CA is the definitive mitigation.
Same technique Authentication Bypass
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today