Description

Cleartext Storage of Sensitive Information in an Environment Variable (CWE-526) in Elastic Cloud on Kubernetes (ECK) can lead to information disclosure via Retrieve Embedded Sensitive Data (CAPEC-37). When ECK reconciles a Fleet Server resource that authenticates to Elasticsearch with a service account token, the token is written into the generated workload specification in cleartext rather than being referenced from the Kubernetes Secret that ECK maintains for the other credentials on the same path. Any principal able to read workload specifications in the affected namespace can therefore read a live Elasticsearch credential, even when Kubernetes RBAC does not grant that principal access to Secrets.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-13T20:17:25.160Z",
  "pubdate": "2026-08-13T20:17:25.160Z",
  "executiveSummary": "A vulnerability classified as Cleartext Storage of Sensitive Information in an Environment Variable (CWE-526) affects Elastic Cloud on Kubernetes (ECK).\nThe flaw allows for information disclosure via Retrieve Embedded Sensitive Data (CAPEC-37).\nThe issue arises when ECK reconciles a Fleet Server resource that authenticates to Elasticsearch using a service account token.\nInstead of referencing the Kubernetes Secret maintained by ECK for credentials, the token is written directly into the generated workload specification in cleartext.\nConsequently, any principal capable of reading workload specifications within the affected namespace can acquire a live Elasticsearch credential.\nThis exposure occurs independently of Kubernetes RBAC configurations that would otherwise restrict direct access to underlying Secrets.\nThe risk includes unauthorized privilege escalation and lateral movement across the cluster by principals possessing read access to standard workload definitions, circumventing standard namespace isolation boundaries for sensitive credentials.",
  "technicalDetails": "The vulnerability resides within the Elastic Cloud on Kubernetes (ECK) operator logic responsible for reconciling Fleet Server resources.\nThe root cause is improper handling of authentication material during the generation of the workload specification.\nWhen Fleet Server authenticates to Elasticsearch via a service account token, ECK fails to reference the secure Kubernetes Secret designated for related credentials on the same path.\nInstead, the sensitive token is serialized directly in cleartext within the environment variables of the generated workload specification.\nThe attack vector requires an attacker or malicious principal to possess read permissions for workload specifications within the targeted namespace.\nAuthentication and privilege requirements are limited to standard read access on workload resources (such as Deployments, StatefulSets, or Pods), bypassing the need for read access to Kubernetes Secrets.\nThe step-by-step attack flow proceeds as follows: First, ECK reconciles a Fleet Server resource, injecting the plaintext service account token into the workload's environment variables. Second, an authenticated principal with workload read permissions queries the API server for the Fleet Server workload specification. Third, the principal extracts the live Elasticsearch credential directly from the exposed environment variables. Finally, the attacker leverages the harvested credential to interact directly with the Elasticsearch cluster, potentially escalating privileges or accessing sensitive data stores.\nThe post-exploitation impact includes unauthorized data access, potential data exfiltration, and compromise of the Elasticsearch backend managed by the affected ECK deployment."
}