Database/Container, Kubernetes & orchestration

ECK operator: unvalidated secret reference lets a namespace-scoped user read secrets from any namespace

CVE-2026-72640Container, Kubernetes & orchestrationcurated

Impact

The ECK operator holds cluster-wide secret permissions and reads a list of secret references from an annotation on the secrets it manages, without checking that the referenced namespace is authorized for the resource being reconciled. A user who can only write in their own namespace can set that annotation, trigger a reconcile, and have the operator copy any secret from any other namespace into one they can read. On a shared GPU cluster that is a direct break of the namespace tenancy boundary: registry pull secrets, service-account tokens, storage and cloud credentials belonging to other tenants or to the platform team all become readable by a single low-privileged tenant. Nothing needs to run on a GPU node - the operator does the exfiltration with its own privileges.

Who can reach it

Any authenticated Kubernetes user or workload identity with write access to secrets in a single namespace that ECK reconciles. No cluster-level permissions and no node access are needed.

What to do

Upgrade the ECK operator to 3.5.0 per the Elastic advisory (ESA-2026-121). This is an operator deployment upgrade - roll the ECK controller pods; managed Elastic workloads are not restarted and GPU nodes do not need to be drained. Treat any secret in a namespace ECK reconciles as potentially exposed if the cluster is multi-tenant: audit secret annotations for unexpected cross-namespace references and rotate credentials that a tenant namespace could have named.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-72640 https://discuss.elastic.co/t/elastic-cloud-on-kubernetes-3-5-0-security-update-esa-2026-121/389494

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.