Kamaji manages Kubernetes control planes for tenants. Before version 26.7.4-edge, it generates a datastore schema, database user, and etcd key prefix from a lossy normalization of the tenant's namespace and name. This normalization can cause two distinct tenants to receive identical datastore identifiers. The result is that control‑plane state, database objects and etcd entries are shared between tenants, providing one tenant the ability to read, modify, or delete another tenant's Kubernetes data. The vulnerability is rooted in access control and identifier collision weaknesses (CWE‑284, CWE‑653).

Any installation of Clastix Kamaji before 26.7.4-edge is vulnerable. The issue is fixed in the 26.7.4-edge release; later releases are unaffected. This applies to all Kubernetes clusters managed by Kamaji that create multiple tenants.

The CVSS score of 8.5 indicates high severity. EPSS score of < 1% indicates a low probability of exploitation. The vulnerability is not listed in the CISA KEV catalog, suggesting no actively exploited variants have been reported. The likely attack vector is an attacker operating as a tenant who creates a namespace or name that collides after normalization. Once this occurs, the attacker can read, modify, or destroy the other tenant’s data without additional privileges. The exploitation path is straightforward and does not require privilege escalation beyond the tenant level. Due to the cross‑tenant data breach potential, the risk to organizations using Kamaji is significant.