GPU VulnDB

Database/Container, Kubernetes & orchestration

HyperShift operator: unvalidated tenant kubeconfig secrets yield code execution in the hosted control plane namespace

CVSS 8.8CVE-2026-101919Container, Kubernetes & orchestrationcurated

Impact

The HyperShift operator copies a user-supplied kubeconfig secret straight into the privileged control plane namespace without validating it. A kubeconfig can declare an exec credential plugin - an arbitrary command line - so when a downstream controller loads the copied config it runs that command inside the control plane. The attacker goes from a namespaced tenant who may create clusters and secrets to code execution in the namespace that holds the hosted cluster's signing keys, etcd credentials and service account tokens. On a multi-tenant GPU cluster where HyperShift hands each team a hosted control plane, that is a cross-tenant escalation: the shared management cluster is the blast radius, not the tenant's own cluster.

Who can reach it

Any authenticated user of the management cluster who holds permission to create a HostedCluster and a secret in a namespace the operator reconciles. No access to the control plane namespace itself is needed.

What to do

Update Multicluster Engine for Kubernetes / the HyperShift operator to the fixed build listed in the Red Hat advisory and let the operator pods restart; no node reboot or GPU workload drain is required. The record does not name a fixed version, so take it from access.redhat.com. Meanwhile, audit who can create HostedCluster and secret objects and review existing kubeconfig secrets in reconciled namespaces for exec credential plugin stanzas.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.