CVE-2025-71423 in Contrast
Summary
by MITRE • 09/27/2026
Edgelesssys Contrast is a confidential-computing runtime for Kubernetes. In versions 1.9.0 before 1.12.2, the initializer logs the full NewMeshCert response — which contains the workload secret — to standard output at INFO level. As a result, workload secrets are exposed to any Kubernetes user with get or list permission on pods/logs. Because workload secrets are used for encrypted storage and Vault integration, those must also be considered compromised. This is a regression of GHSA-h5f8-crrq-4pw8.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability identified in Edgeless Systems Contrast versions prior to 1.12.2 represents a critical information disclosure flaw within the confidential computing runtime environment for Kubernetes. The root cause lies in the logging configuration of the initializer component, which is responsible for establishing secure communication channels and managing cryptographic materials for workloads running inside trusted execution environments. Specifically, during the initialization phase, the system generates a NewMeshCert response that includes sensitive workload secrets required for subsequent operations such as encrypted storage access and integration with HashiCorp Vault. Instead of suppressing or redacting these high-value credentials from the log output, the application logs the full response payload at the INFO level to standard output. This design oversight transforms routine operational logging into a significant security risk, effectively creating an unencrypted channel for secret transmission within the Kubernetes cluster's internal communication infrastructure.
The operational impact of this vulnerability is severe due to the broad accessibility of container logs in typical Kubernetes deployments. Any user or service account possessing get or list permissions on pod logs can retrieve these plaintext secrets simply by viewing the initialization logs of affected pods. This access pattern aligns with common least-privilege violations where developers, CI/CD pipelines, or monitoring agents are granted read access to logs for debugging and observability purposes without realizing they are also gaining access to cryptographic keys and authentication tokens. Since workload secrets serve as the foundation for encrypted storage mechanisms and Vault integration, their exposure compromises not only the immediate application but potentially downstream systems that rely on these credentials for data protection and identity management. The compromise of these secrets allows attackers to decrypt stored data, impersonate services within the mesh network, or escalate privileges by leveraging stolen tokens against external vaults.
This issue is classified as CWE-532, which covers information exposure through log files, a category of vulnerabilities where sensitive data is inadvertently written to logs that may be accessible to unauthorized parties. Furthermore, from an adversary perspective, this vulnerability facilitates the ATT&CK technique T1078, Valid Accounts, by allowing attackers to obtain legitimate credentials for internal services and infrastructure components without needing to exploit additional software flaws or perform complex network attacks. The ease of exploitation means that even users with minimal permissions can pivot into deeper parts of the cluster architecture once they extract these secrets from log streams. This represents a regression of previously identified security issues, specifically referencing GHSA-h5f8-crrq-4pw8, indicating a failure to maintain strict logging hygiene standards across updates and highlighting the need for rigorous review of secret handling practices in runtime components.
Mitigation strategies must focus on immediate remediation through version upgrades as well as architectural adjustments to prevent future occurrences. The primary corrective action is to upgrade Edgeless Systems Contrast to version 1.12.2 or later, where this logging behavior has been corrected to exclude sensitive data from standard output logs. In the interim, administrators should implement strict log access controls by restricting get and list permissions on pod logs to only those service accounts that absolutely require them for operational purposes. Additionally, organizations should audit their Kubernetes RBAC policies to ensure that default roles do not grant excessive logging privileges to general users or automated tools. Long-term mitigation involves adopting a zero-trust approach to logging within confidential computing environments by ensuring that all sensitive data is redacted before being written to any log stream and implementing monitoring solutions that detect anomalous access patterns to pod logs, thereby providing early warning of potential credential theft attempts.