Executive brief
Elastic Cloud on Kubernetes (ECK) inadvertently stores Elasticsearch service account authentication tokens in cleartext within workload specifications, rather than securely referencing them from Kubernetes Secrets. This allows any user with permission to read workload specifications in a Kubernetes namespace to access live Elasticsearch credentials, even if they lack authorization to read Secrets directly. This could enable unauthorized access to Elasticsearch databases and sensitive data they contain.
Technical details
The vulnerability is a cleartext storage issue (CWE-526) in ECK's reconciliation logic for Fleet Server resources. When ECK processes a Fleet Server resource configured to authenticate to Elasticsearch using a service account token, it embeds the token directly in the generated workload specification (Pod, Deployment, or similar) rather than referencing the Kubernetes Secret that holds other credentials. An attacker with workload read access (via Kubernetes RBAC permissions) can extract the token from workload manifests and authenticate directly to Elasticsearch. The attack requires legitimate Kubernetes namespace access but bypasses Secret-level access controls. The vulnerability affects all 3.x versions from 3.0.0 through 3.4.1, and is resolved in version 3.5.0. Elastic recommends invalidating and rotating affected service account tokens after upgrading.
Affected products
- Elastic Cloud on Kubernetes 3.0.0 through 3.4.1
Timeline
- 2026-08-13: disclosed
- 2026-08-13: patched: Fixed in version 3.5.0