Contrast Initializer Leaks Workload Secret to stdout (CVE-2025-71423)

Executive Summary

A high-severity information disclosure vulnerability (CVE-2025-71423) has been disclosed in Contrast, Edgeless Systems' confidential-computing runtime for Kubernetes. In versions 1.9.0 through 1.12.1, the Contrast initializer logs the full NewMeshCert response — which contains the workload secret — to standard output at INFO log level. Because INFO is a commonly enabled (and often default) log level, workload secrets end up in Kubernetes-collected pod logs, exposing them to any Kubernetes user with get or list permission on pods/logs.

This CVE is a regression of a previously fixed issue (GHSA-h5f8-crrq-4pw8), meaning the underlying logging bug was reintroduced after having already been remediated once.

CVSS Score: 7.3 (High) Fixed in: Contrast 1.12.2

Vulnerability Overview

Technical Details

Root Cause

Contrast's initializer container requests a mesh certificate from the Coordinator via a NewMeshCert call. The response to that call includes the workload secret — a value that should only ever be accessible to the Coordinator, the initializer itself, the seedshare owner, and the workload owner. Instead of handling this response value carefully, the initializer logs the entire response object to stdout at INFO level, which Kubernetes captures as standard pod logs.

Why It Matters

Workload secrets in Contrast are not incidental values — they underpin encrypted storage and Vault integration for the confidential workload. Once logged, a secret must be treated as fully compromised: anyone who can read the initializer's pod logs (a common, low-privilege Kubernetes RBAC capability, and one also available to cloud providers hosting the log storage) can recover it directly, with no additional exploitation required.

Attack Chain

1. A Contrast-protected workload starts; its initializer container
   calls NewMeshCert against the Coordinator
 
2. The initializer logs the full response — including the workload
   secret — to stdout at INFO level
 
3. Kubernetes captures container stdout as pod logs by default
 
4. Any principal with get/list on pods/logs (or read access to
   wherever cluster logs are shipped, e.g. a cloud logging backend)
   retrieves the workload secret directly from the logs
 
5. The attacker uses the recovered workload secret to decrypt
   encrypted storage or impersonate the workload against Vault

Impact Assessment

Recommendations

Immediate Actions

1. Upgrade to Contrast 1.12.2 or later without delay.
2. Rotate all workload secrets for any workload that ran an affected initializer version (1.9.0–1.12.1), since historical log retention may still contain the exposed value.
3. Audit log retention and access — review who has had get/list access to pods/logs for affected namespaces during the exposure window, and check log-shipping destinations (e.g. cloud logging services) for retained copies.
4. Re-establish trust in encrypted storage and Vault integrations tied to any exposed workload secret — treat associated data as potentially accessible to unauthorized parties until secrets are rotated.

Detection

• Search historical pod logs and any downstream log aggregation systems for NewMeshCert response payloads or workload-secret-shaped strings.
• Audit RBAC bindings granting pods/logs access and tighten to least privilege where broader than necessary.

References

• GitHub Security Advisory — regression of GHSA-h5f8-crrq-4pw8
• VulDB — CVE-2025-71423
• Contrast (Edgeless Systems)
• CWE-532: Insertion of Sensitive Information into Log File