Database/Container, Kubernetes & orchestration

Elastic Cloud on Kubernetes: namespace-scoped user injects CA material into another namespace's trust bundle

CVE-2026-78609Container, Kubernetes & orchestrationcurated

Impact

ECK runs as a cluster-wide operator, and Elastic reports that an actor holding limited Kubernetes permissions confined to a single namespace can cause attacker-controlled certificate material to end up in the Elasticsearch client trust bundle that ECK manages in a separate namespace. That crosses the namespace boundary a GPU cluster normally relies on to separate teams or tenants: permissions granted for one team's namespace reach into another's. With a CA of their choosing trusted, the attacker can present certificates the Elasticsearch client accepts, which is a route to intercepting or spoofing the cluster's log and metrics traffic. Elastic classes it as incorrect authorization via metadata spoofing and scores it 5.4 with low confidentiality and integrity impact - unauthorized modification of data, not cluster takeover.

Who can reach it

An authenticated Kubernetes user or workload with limited permissions confined to a single namespace - enough to create the resources ECK reconciles. No cluster-admin rights and no access to the target namespace are required.

What to do

Upgrade the ECK operator to 3.5.0 per ESA-2026-145. Cost is rolling the operator deployment in the cluster; the managed Elasticsearch pods are not restarted by the operator upgrade itself, so there is no GPU node drain and no reboot. After upgrading, review the trust bundles ECK manages for certificate material nobody on your team added.

References

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

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.