Kamaji: colliding tenant name normalization lets one tenant read or destroy another's control-plane state

Impact

Kamaji builds each TenantControlPlane's datastore schema, database user and etcd key prefix by normalizing namespace and name, and the normalization is lossy. Two tenants whose namespace/name pairs normalize to the same string end up pointed at the same backing store, so one tenant's control plane can read, modify or delete the other's Kubernetes objects - including secrets, RBAC and workload definitions. For an operator running hosted Kubernetes control planes for separate customers on a shared GPU fleet, this is a break of the boundary the whole product exists to enforce: a tenant that lands on a colliding name gets another tenant's cluster state without touching the network path between them. Whether a given deployment is affected depends on the tenant names in use, so the first step is to check existing TenantControlPlane names for collisions rather than to assume exposure.

Who can reach it

A tenant who can create or name a TenantControlPlane (or an operator-driven onboarding flow that accepts tenant-supplied names) in a Kamaji-managed cluster. Authentication to the management cluster is required, at the level normally granted to a tenant; no access to the victim's control plane is needed.

What to do

Upgrade Kamaji to 26.7.4-edge and roll the manager deployment, which is a controller restart in the management cluster and does not touch tenant worker nodes or GPU workloads. Before and after the upgrade, audit existing TenantControlPlane namespace/name pairs for ones that normalize to the same schema, user or etcd prefix - the advisory does not state that the fix remaps already-provisioned tenants, so a collision created before the upgrade may need manual separation of the datastore schema and etcd prefix.

References

Related entries

• Docker / moby: Command execution via crafted remote git build path in `docker build`CVE-2019-13139 · Docker / mobyHigh
• Rancher: Sensitive data leaked into Rancher audit logsCVE-2023-22649 · RancherHigh
• runc: Insufficient checks when bind-mounting /dev/console allow writes to arbitrary host procfs pathsCVE-2025-52565 · runcHigh
• BuildKit: Custom frontend can craft an API message causing daemon compromiseCVE-2026-33747 · BuildKitHigh
• Helm: Crafted plugin writes its contents to an arbitrary filesystem location on install or updateCVE-2026-35204 · HelmHigh
• Helm: Helm installs plugins with no provenance file even when signature verification is requiredCVE-2026-35205 · HelmHigh