Executive brief
Kamaji, a tool used to manage multiple Kubernetes clusters within a single environment, suffers from a flaw in how it separates data between different customers (tenants). Due to a naming error, two different customers could end up sharing the same database storage and login credentials if their project names are similar. This would allow one customer to view, modify, or delete all of another customer's sensitive Kubernetes data, including secrets and access tokens.
Technical details
Kamaji's `GetDefaultDatastoreSchema()` and `GetDefaultDatastoreUsername()` functions use a lossy normalization logic: `strings.ReplaceAll(fmt.Sprintf("%s_%s", namespace, name), "-", "_")`. Because both the join character and the replacement for dashes are underscores, distinct (namespace, name) pairs like ("a-b", "c") and ("a", "b-c") collide to the same identifier ("a_b_c"). When a collision occurs, the idempotent datastore reconciler silently reuses the existing database schema, user, and permissions. An attacker with permissions to create `TenantControlPlane` resources can intentionally craft a colliding name to gain full access to a victim tenant's etcd or SQL datastore, enabling them to read or modify all Kubernetes objects (Secrets, ServiceAccounts, RBAC) of the victim. This issue is fixed in version 26.7.4-edge by switching to UIDs for identification.
Affected products
- Clastix Kamaji < 26.7.4-edge
Timeline
- 2026-07-14: advisory: GitHub Advisory GHSA-4f3f-65vx-r34f published
- 2026-07-30: disclosed: CVE-2026-62246 published to NVD
- 2026-07-30: patched: Fixed in version 26.7.4-edge