CVE-2025-71426

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.

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.

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.

Impact

Recovering coordinators do not verify the seed provided by the recovering party. This allows an attacker to set up a coordinator with a manifest that passes validation, but with a secret seed controlled by the attacker.

If network traffic is redirected from the legitimate coordinator to the attacker's coordinator, a workload owner is susceptible to impersonation if either

• they set a new manifest and don't compare the root CA cert with the existing one (this is the default of the contrast CLI) or
• they verify the coordinator and don't compare the root CA cert with a trusted reference.

Under these circumstances, the attacker can:

• Issue certificates that chain back to the attacker coordinator's root CA.
• Recover arbitrary workload secrets of workloads deployed after the attack.

This issue does not affect the following:

• secrets of the legitimate coordinator (seed, workload secrets, CA)
• integrity of workloads, even when used with the rogue coordinator
• certificates chaining back to the mesh CA

Patches

This issue is patched in Contrast v1.4.1.

Workarounds

The issue can be avoided by verifying the coordinator root CA cert against expectations.

• At the first set call, keep a copy of the CA cert returned by the coordinator.
• After subsequent set or verify calls, compare the returned CA cert with the backup copy. If it matches bit-for-bit, the coordinator is legitimate.

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.

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.

Impact

Recovering coordinators do not verify the seed provided by the recovering party. This allows an attacker to set up a coordinator with a manifest that passes validation, but with a secret seed controlled by the attacker.

If network traffic is redirected from the legitimate coordinator to the attacker's coordinator, a workload owner is susceptible to impersonation if either

• they set a new manifest and don't compare the root CA cert with the existing one (this is the default of the contrast CLI) or
• they verify the coordinator and don't compare the root CA cert with a trusted reference.

Under these circumstances, the attacker can:

• Issue certificates that chain back to the attacker coordinator's root CA.
• Recover arbitrary workload secrets of workloads deployed after the attack.

This issue does not affect the following:

• secrets of the legitimate coordinator (seed, workload secrets, CA)
• integrity of workloads, even when used with the rogue coordinator
• certificates chaining back to the mesh CA

Patches

This issue is patched in Contrast v1.4.1.

Workarounds

The issue can be avoided by verifying the coordinator root CA cert against expectations.

• At the first set call, keep a copy of the CA cert returned by the coordinator.
• After subsequent set or verify calls, compare the returned CA cert with the backup copy. If it matches bit-for-bit, the coordinator is legitimate.

Contrast's unauthenticated recovery allows Coordinator impersonation in github.com/edgelesssys/contrast