What is the CVSS score of CVE-2026-16242?

CVE-2026-16242 has a CVSS 3.1 base score of 9.4 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L. EPSS exploitation probability: 0.4%.

Which versions of OpenShift HyperShift are affected by CVE-2026-16242?

Red Hat OpenShift HyperShift installations are exposed to a critical remote authentication bypass (CVE-2026-16242) that allows attackers to intercept and tamper with Kubernetes cluster…

How to fix or mitigate CVE-2026-16242?

Within 24 hours, inventory all Red Hat OpenShift HyperShift deployments and assess network accessibility of Konnectivity endpoints to prioritize remediation scope. Within 7 days, engage Red Hat support to confirm patch timelines and implement network-based mitigations to restrict access to Konnectivity endpoints from authorized infrastructure only. Within 30 days, deploy the vendor patch to all affected HyperShift deployments immediately upon release and conduct post-remediation validation.

OpenShift HyperShift CVE-2026-16242

EUVD-2026-45897 CRITICAL

Missing Authentication for Critical Function (CWE-306)

2026-07-20 secalert@redhat.com

GHSA-43hh-68v6-mf36

Authentication Bypass

9.4

CVSS 3.1 · Vendor: redhat

Severity by source

Vendor (redhat) PRIMARY

9.4 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L

vuln.today AI

10.0 CRITICAL

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.

3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:H/SI:H/SA:L

Red Hat

9.4 CRITICAL

qualitative

Primary rating from Vendor (redhat).

CVSS VectorVendor: redhat

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

Low

Lifecycle Timeline

Source Code Evidence Fetched

Jul 20, 2026 - 08:31 vuln.today

Analysis Generated

Jul 20, 2026 - 08:31 vuln.today

CVE Published

Jul 20, 2026 - 08:16 nvd

CRITICAL 9.4

DescriptionCVE.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.