REDHAT-BUG-2542541: High severity Red Hat HyperShift operator vulnerability
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
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update ReconcileCredentials so user-provided kubeconfig Secrets referenced by HostedCluster spec.platform.kubevirt.credentials.infraKubeConfigSecret are validated and sanitized before their data is copied into the control plane namespace.
HyperShift operator ReconcileCredentials kubeconfig validation and sanitization = Reject or sanitize kubeconfig content containing exec providers, AuthProvider entries, InsecureSkipTLSVerify, or BearerTokenFile before copying it into the privileged control plane namespace
Event History
Frequently Asked Questions
Who can introduce malicious kubeconfig content?
A tenant that has permission to create HostedCluster resources and Secrets in its namespace can do so by referencing a Secret through HostedCluster spec.platform.kubevirt.credentials.infraKubeConfigSecret.
What happens to the supplied Secret after reconciliation?
The operator copies every entry from the source Secret's Data field into a Secret in the control plane namespace. The copied kubeconfig can then be consumed by downstream controllers, including CAPK.
What kubeconfig protections are missing during the copy?
The operator does not strip exec credential providers or validate AuthProvider configuration. It also does not guard against InsecureSkipTLSVerify or BearerTokenFile settings.
Is patching CAPK's exec-provider handling alone sufficient?
No. The issue is described as independent of CAPK exec-provider RCE behavior; the HyperShift operator should validate kubeconfig content before placing it in the privileged control plane namespace.