CVE-2026-101919: Hypershift: hypershift: unsanitized kubeconfig passthrough from tenant namespace to control plane
A flaw was found in the HyperShift operator. In the ReconcileCredentials function, the operator copies a user-provided kubeconfig Secret (referenced via HostedCluster spec.platform.kubevirt.credentials.infraKubeConfigSecret) verbatim into the control plane namespace without any validation or sanitization:
for k, v := range sourceSecret.Data { targetSecret.Data[k] = v }
No exec-provider stripping, no AuthProvider validation, no InsecureSkipTLSVerify guard, and no BearerTokenFile check is performed. This allows a tenant with HostedCluster and Secret creation permissions in their namespace to inject arbitrary kubeconfig content - including exec credential plugins - into the control plane namespace where it is consumed by downstream controllers (such as CAPK).
This is a defense-in-depth failure independent of the CAPK exec-provider RCE. Even after CAPK is patched to strip exec providers, the HyperShift operator should validate kubeconfig content before copying it into the privileged control plane namespace.
Identified during Red Hat ProdSec analysis of the CAPK exec-provider report (PSIRTSUPT-24794).
Source repo: https://github.com/openshift/hypershift
Other sources
A flaw was found in the HyperShift operator. The operator copies user-provided Kubernetes configuration (kubeconfig) secrets directly into the privileged control plane namespace without proper validation or sanitization. An authenticated user with cluster and secret creation permissions can exploit this vulnerability by supplying a configuration containing unauthorized executable plugins. When downstream controllers consume this configuration, an attacker can achieve arbitrary code execution within the control plane.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the HyperShift operator's ReconcileCredentials function, validate and sanitize the user-provided kubeconfig referenced by HostedCluster spec.platform.kubevirt.credentials.infraKubeConfigSecret before copying it into the privileged control plane namespace: strip exec providers, validate AuthProvider entries, reject InsecureSkipTLSVerify, and reject BearerTokenFile configuration.
Event History
Frequently Asked Questions
What access would an attacker need to exploit this issue?
The attacker needs permission to create or control a HostedCluster and to create a Secret in the tenant namespace. They must be able to set the HostedCluster's infraKubeConfigSecret reference to that Secret.
Why is patching a downstream controller such as CAPK not sufficient by itself?
The operator copies the supplied kubeconfig into the privileged control-plane namespace without validation or sanitization. This flaw remains a defense-in-depth concern even if CAPK strips exec credential providers, because HyperShift should prevent unsafe kubeconfig content from crossing that namespace boundary.
Which kubeconfig content is not checked before it is copied?
The described copy operation does not strip exec providers or validate AuthProvider configuration. It also does not guard against InsecureSkipTLSVerify or BearerTokenFile settings.