Database/Container, Kubernetes & orchestration

Kamaji: unescaped datastore username/schema fields give SQL injection on the shared tenant datastore

CVSS 4.7CVE-2026-62845Container, Kubernetes & orchestrationcurated

Impact

Kamaji builds DDL for the PostgreSQL and MySQL datastore drivers with fmt.Sprintf over the DataStoreUsername and DataStoreSchema fields, and neither field has format validation. A quote character in either value escapes the quoted identifier, and the resulting SQL runs over Kamaji's root connection to the datastore. That datastore is shared: it backs the control planes of every tenant cluster Kamaji manages, so a value injected while provisioning one tenant control plane executes with full rights against the storage of all of them. Operators who hand out managed Kubernetes clusters on a GPU fleet should treat this as a tenant-boundary issue in the control plane, not a database bug. The etcd driver is not affected.

Who can reach it

An authenticated user with enough privilege to create or edit TenantControlPlane resources in the management cluster - the vendor scores it PR:H. Not reachable from a tenant workload pod.

What to do

Upgrade Kamaji to 26.7.4-edge and restart the Kamaji controller manager; the fix is a change in the datastore drivers, so no tenant control plane or GPU node has to be drained. Until then, restrict who can create or mutate TenantControlPlane objects and use only etcd-backed datastores for new tenants.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-62845 https://github.com/clastix/kamaji/security/advisories/GHSA-r47v-ppwp-fh4r https://github.com/clastix/kamaji/commit/6a9f3e10ae408e7948e2aca2db694791a299e79c https://github.com/clastix/kamaji/releases/tag/26.7.4-edge

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.