Advisory · CVE-2026-101919
HyperShift copies tenant kubeconfig into the control plane, unsanitized
The HyperShift operator copies user-supplied kubeconfig secrets into the privileged control plane namespace without validation, so an authenticated tenant user can smuggle in an executable plugin and gain code execution in the control plane.
- Vendor
- Red Hat
- Product
- Multicluster Engine for Kubernetes
- Identifier / CWE
- CVE-2026-101919
CWE-20 - Action timing
- Immediate
Explain it like I’m five
HyperShift takes a tenant's configuration file and moves it into the building's most trusted room without checking what's inside. A tenant can hide a program inside that file, and when the building's own machinery reads the file, the hidden program runs with the building's privileges.
- 01Tenant crafts a kubeconfig
An authenticated user with cluster and secret creation permissions in a tenant namespace creates a secret containing a kubeconfig with an embedded executable plugin.
- 02Operator copies verbatim
The HyperShift operator copies the secret into the privileged control plane namespace without validating or sanitizing its contents.
- 03Downstream controllers consume it
Management controllers on the hosting cluster read the forwarded configuration to reach tenant resources.
- 04Plugin executes
The embedded executable plugin runs with the controllers' privileges, breaking tenant isolation and reaching the host control plane.
What happened
Red Hat disclosed a flaw in the HyperShift operator shipped with Multicluster Engine for Kubernetes. The operator copies user-provided kubeconfig secrets from tenant namespaces directly into the privileged control plane namespace without validation or sanitization. An authenticated user holding cluster and secret creation permissions in a tenant namespace can supply a kubeconfig containing an unauthorized executable plugin; when downstream controllers consume that configuration, the plugin executes in the control plane.
Red Hat rates the issue Important at CVSS 8.8 and states that no mitigation meeting its usability and stability criteria is currently available. The practical effect is a tenant-isolation break: a tenant with standard resource-creation privileges can compromise hosting infrastructure components.
What to do
- Inventory OpenShift environments using Multicluster Engine for Kubernetes with HyperShift.
- Apply the Red Hat-provided fix once available, following the Red Hat security bulletin guidance.
- Limit tenant-namespace creation privileges to trusted identities where possible, since the exploit needs cluster and secret creation rights in a tenant namespace.
- Restrict which namespaces and identities can create HostedClusters and secrets consumed by the operator.
- Monitor for secrets containing kubeconfig data with unexpected exec-provider or plugin references in tenant namespaces.
- Review control plane and management-controller activity for signs of unexpected binary execution tied to tenant-provided configuration.
Management note
This breaks a boundary that multi-tenant Kubernetes operators must hold: tenant-supplied data is reaching the privileged control plane unfiltered. Because Red Hat offers no standalone mitigation, the answer is patching plus tighter tenant permissions until the fix lands. Any environment sharing hosting infrastructure between tenants should treat this as a scheduled patch with an accelerated timeline.