Description

Contrast (Edgeless Systems) before 1.8.1 logs the workload secret to stderr, and thus to Kubernetes logs, when the Contrast initializer is configured with CONTRAST_LOG_LEVEL set to info or debug. Because info is the default, all installations that do not customize the initializer log level are affected. This exposes workload secrets — normally accessible only to the Contrast Coordinator, the initializer, the seedshare owner, and the workload owner — to Kubernetes users with get or list permission on pods/logs and to anyone with read access to the Kubernetes log storage, such as the cloud provider. Deployments that do not use workload secrets are unaffected.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.3",
  "pubDate": "2026-09-27T02:17:16.797Z",
  "pubdate": "2026-09-27T02:17:16.797Z",
  "executiveSummary": "A sensitive information disclosure vulnerability exists in Contrast (Edgeless Systems) versions prior to 1.8.1, where workload secrets are inadvertently written to standard error (stderr).\nBecause the default configuration for the Contrast initializer utilizes an 'info' logging level, the vulnerability is enabled by default across all standard deployments.\nThe exposure of workload secrets to the Kubernetes logging infrastructure allows unauthorized entities with log-read permissions—such as those with 'get' or 'list' privileges on pods/logs—to gain access to highly sensitive credentials that should be restricted to the Contrast Coordinator and the workload owner.\nThis vulnerability presents a significant risk to data confidentiality and infrastructure integrity, as leaked secrets could facilitate unauthorized access to encrypted data or further privileged escalation within the protected workload environment.\nExploitation requires no complex interaction from an attacker; if the attacker possesses sufficient Kubernetes RBAC permissions to read pod logs or access the underlying log storage aggregation layer provided by the cloud platform, the secret material can be trivially harvested.",
  "technicalDetails": "The root cause of this vulnerability lies in the Contrast initializer's logging implementation, which fails to scrub sensitive workload secrets from standard error output when configured with a logging level of 'info' or 'debug'.\nIn the affected versions (prior to 1.8.1), the application runtime is configured to output initialization artifacts to stderr, which is automatically captured and persisted by the Kubernetes container engine.\nBecause 'info' is the default log level for the initializer, any deployment utilizing default settings will implicitly leak secrets upon the instantiation of the workload container.\nThe attack flow proceeds as follows: 1) The Contrast initializer executes upon container startup; 2) The initializer process retrieves the workload secret to establish secure communications or state; 3) The initializer emits log messages via stderr, inadvertently embedding the raw workload secret in the string output; 4) The Kubernetes kubelet captures this stderr stream and directs it to the log storage backend; 5) An attacker with RBAC permissions for 'get' or 'list' on pods/logs retrieves the log stream through the Kubernetes API or directly from the storage sink (e.g., CloudWatch, Stackdriver, or persistent log volumes).\nThe security boundary between the secret-authorized components (Coordinator, initializer, seedshare owner, workload owner) and the Kubernetes logging infrastructure is violated, as the logs are accessible to any user or service account with read access to the pod's logging telemetry.\nThis exposure is persistent, meaning the secret remains in the log history even after the initial workload container terminates. The lack of sanitization logic within the initializer's logger means that the secret is treated as plain-text metadata, effectively bypassing the memory isolation guarantees typically afforded to protected secrets.\nWhile this does not require authenticated access to the internal Contrast application logic, it requires the attacker to have a foothold within the Kubernetes cluster's RBAC scope. If the logging system exports to an external, less-secure log management platform, the blast radius of this disclosure can extend beyond the cluster's native RBAC controls, providing adversaries with persistent access to credentials that facilitate further system compromise."
}