CVE-2025-71426: Contrast before 1.4.1 Coordinator Impersonation via Unauthenticated Recovery
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Contrastto a version that resolves this vulnerability.Fixed in 1.4.1 - Compensating control
When setting a new manifest or verifying the Coordinator, compare the returned root CA certificate against the existing certificate or a trusted reference.
Event History
Frequently Asked Questions
What conditions must an attacker meet to impersonate a workload owner?
The attacker must redirect network traffic from the legitimate Coordinator to a rogue Coordinator and supply an attacker-controlled seed during recovery. The workload owner must then accept a new manifest without comparing the returned root CA certificate to the existing certificate, or perform verification without comparing that certificate to a trusted reference.
Is the default CLI workflow affected?
Yes. The Contrast CLI's default behavior does not compare the returned root CA certificate against the existing one when setting a new manifest, which can allow the impersonation condition described in the advisory.
What is exposed if the attack succeeds?
The attacker can issue certificates chaining to the rogue Coordinator's root CA and recover arbitrary workload secrets for workloads deployed after the attack. The legitimate Coordinator's seed, workload secrets, CA, workload integrity, and certificates chaining to the mesh CA are not affected.
What can be done if upgrading is not immediately possible?
When setting a new manifest or verifying a Coordinator, compare the returned root CA certificate against the existing certificate or another trusted reference. This prevents accepting the rogue Coordinator described in the advisory.