Description

Contrast is a confidential-computing runtime for Kubernetes. In versions before 1.4.1, a recovering Coordinator does not verify the seed supplied by the recovering party. An attacker can therefore stand up a rogue Coordinator whose manifest passes validation but whose secret seed is attacker-controlled. If network traffic is redirected from the legitimate Coordinator to the attacker's Coordinator, a workload owner can be impersonated when they either set a new manifest without comparing the returned root CA certificate against the existing one (the default behavior of the contrast CLI) or verify the Coordinator without comparing the root CA certificate against a trusted reference. Under these conditions the attacker can issue certificates that chain back to the rogue Coordinator's root CA and recover arbitrary workload secrets of workloads deployed after the attack. Secrets of the legitimate Coordinator (seed, workload secrets, CA), workload integrity, and certificates chaining to the mesh CA are not affected.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-27T02:17:17.160Z",
  "pubdate": "2026-09-27T02:17:17.160Z",
  "executiveSummary": "A critical security vulnerability exists in Contrast versions prior to 1.4.1 due to an improper verification mechanism during the Coordinator recovery process. Specifically, the Coordinator fails to authenticate the seed provided by the recovering party.\nThis flaw allows an attacker to instantiate a rogue Coordinator with an arbitrary secret seed that passes manifest validation. By redirecting network traffic from a legitimate Coordinator to the attacker-controlled instance, a malicious actor can successfully impersonate the workload owner.\nThe primary risk involves the unauthorized issuance of certificates chaining back to the attacker's rogue root CA. Consequently, an attacker can intercept and decrypt sensitive workload secrets for services deployed post-compromise.\nExploitation requires successful redirection of network traffic and relies on the default behavior of the Contrast CLI, which does not enforce strict validation of the returned root CA certificate against a trusted reference. While the legitimate Coordinator's internal secrets, workload integrity, and existing mesh CA remain uncompromised, the confidentiality of new secrets is directly at risk.\nThe vulnerability represents a significant break in the trust chain within the confidential-computing environment, necessitating immediate updates and strict verification protocols by operators.",
  "technicalDetails": "The root cause of this vulnerability is a missing verification check in the recovery logic of the Coordinator component within Contrast versions before 1.4.1. When a Coordinator undergoes recovery, the protocol expects the recovering party to provide a seed; however, the Coordinator fails to cryptographically verify the legitimacy of this seed.\nThe attack vector involves an adversary deploying a rogue Coordinator. Because the validation logic only checks the integrity of the manifest—rather than the authenticity of the seed—the malicious Coordinator is accepted as legitimate by the recovery process. An attacker can set a manifest that satisfies all schema requirements while embedding an attacker-controlled secret seed.\nThe exploitation flow proceeds as follows: 1) The attacker successfully intercepts or redirects network traffic destined for the legitimate Coordinator toward the rogue instance. 2) Upon a recovery attempt, the rogue Coordinator presents its malicious seed. 3) Because the verification process is deficient, the system accepts this seed, establishing a trust relationship with the rogue entity. 4) The attacker's Coordinator acts as a valid authority, allowing the generation of certificates that chain back to the attacker's rogue root CA. 5) When a workload owner interacts with the system using the default Contrast CLI—which does not mandate the manual comparison of the returned root CA against a trusted local reference—they inadvertently trust the attacker's chain.\nPost-exploitation, the attacker is positioned to issue arbitrary certificates. Any workloads deployed subsequent to the attack are vulnerable to interception. Since the attacker controls the CA for the compromised session, they can effectively decrypt traffic and recover secrets associated with these specific workloads. It is important to note that this flaw does not allow for the recovery of the legitimate Coordinator's original seed, existing mesh CA secrets, or compromise the integrity of already deployed workloads; the impact is constrained to the specific trust boundary governed by the rogue Coordinator.\nThis attack requires the adversary to have the capability to manipulate network routing or DNS to force traffic toward the malicious Coordinator. The reliance on the CLI's default configuration, which lacks mandatory pinned-certificate verification, serves as a significant force multiplier for the attacker, as it allows the impersonation to succeed without triggering immediate user-side warnings."
}