CVE-2026-62246 in kamaji
Summary
by MITRE • 07/31/2026
Kamaji is the Hosted Control Plane Manager for Kubernetes. Prior to 26.7.4-edge, Kamaji derives a TenantControlPlane datastore schema, database user, and etcd key prefix from a lossy namespace-and-name normalization in GetDefaultDatastoreSchema() and GetDefaultDatastoreUsername(), allowing distinct tenants with colliding normalized identifiers to share control-plane state and read, modify, or destroy another tenant's Kubernetes data. This issue is fixed in version 26.7.4-edge.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/31/2026
The vulnerability in Kamaji represents a critical authorization and data isolation flaw that undermines the fundamental security model of hosted Kubernetes control planes. This issue affects versions prior to 26.7.4-edge where the system employs a lossy normalization process when generating datastore schema names, database usernames, and etcd key prefixes. The normalization functions GetDefaultDatastoreSchema() and GetDefaultDatastoreUsername() transform tenant identifiers through a process that eliminates distinguishing characteristics, creating potential collisions between seemingly different tenant configurations.
The technical implementation of this vulnerability stems from inadequate input sanitization and identifier generation mechanisms within the Kamaji control plane management system. When multiple tenants create resources with names that, after normalization, produce identical strings, the system assigns them shared underlying datastore resources. This lossy transformation process violates the principle of least privilege and data separation that is fundamental to multi-tenant cloud environments. The normalized identifiers lose their uniqueness properties through processes such as converting to lowercase, removing special characters, or truncating names, which creates predictable collision points.
The operational impact of this vulnerability extends far beyond simple data confusion, creating a severe risk of cross-tenant data leakage and potential system compromise. An attacker who can identify or predict collision conditions could exploit this weakness to access another tenant's Kubernetes cluster state, manipulate control plane configurations, or even delete critical infrastructure components. The shared datastore schema means that one tenant's operations could inadvertently affect another's cluster stability, while shared database users create opportunities for unauthorized data access and modification. Additionally, the etcd key prefix collision allows for direct manipulation of another tenant's cluster configuration data, potentially enabling privilege escalation attacks.
This vulnerability maps directly to CWE-20: Improper Input Validation and CWE-352: Cross-Site Request Forgery within the context of multi-tenant Kubernetes orchestration environments. The issue also aligns with ATT&CK technique T1078.004: Valid Accounts - Cloud Accounts, as it enables unauthorized access to another tenant's resources through predictable identifier collisions. Organizations relying on Kamaji for hosted control plane management face significant operational risks including data breaches, service disruption, and potential compliance violations under regulations such as GDPR, HIPAA, or SOC 2. The attack surface expands when considering that these collisions could be triggered through predictable naming conventions or by exploiting the system's lack of proper validation.
Mitigation strategies should focus on implementing proper identifier validation and normalization processes that preserve uniqueness even after transformation. Organizations must ensure that all tenant identifiers undergo strict validation before being used in datastore generation functions, and that collision detection mechanisms are implemented at the point of resource creation. The fix in version 26.7.4-edge addresses this by enhancing the normalization logic to maintain proper identifier uniqueness while preserving backward compatibility for legitimate use cases. Regular security audits should verify that all tenant resources are properly isolated and that no identifiers can produce duplicate datastore configurations, ensuring that multi-tenant environments maintain their security guarantees.