Contrast Coordinator Recovery Seed Verification Bypass (CVE-2025-71426)

Executive Summary

A high-severity authentication/verification bypass (CVE-2025-71426) has been disclosed in Contrast, Edgeless Systems' confidential-computing runtime for Kubernetes. In versions before 1.4.1, a recovering Contrast Coordinator does not verify the seed supplied by the party performing recovery. This allows an attacker to stand up a rogue Coordinator whose manifest passes validation but whose secret seed is entirely attacker-controlled — opening the door to workload-owner impersonation if the attacker can redirect network traffic away from the legitimate Coordinator.

CVSS Score: 7.1 (High) Fixed in: Contrast 1.4.1

Vulnerability Overview

Technical Details

Root Cause

Contrast's Coordinator supports a recovery flow that reconstructs its state from a secret seed. Prior to 1.4.1, the recovery process did not verify that the supplied seed actually originated from a trusted source. An attacker can supply an arbitrary, attacker-controlled seed to stand up a Coordinator instance whose manifest still passes validation — because manifest validation and seed provenance are independent checks, and only the latter was missing.

Attack Chain

1. Attacker stands up a rogue Coordinator, seeded with an
   attacker-controlled secret seed, presenting a manifest that
   passes normal validation
 
2. Attacker redirects network traffic intended for the legitimate
   Coordinator to the rogue instance (e.g. via DNS manipulation,
   network-level MITM, or compromised routing within the cluster)
 
3. A workload owner interacts with what they believe is the
   legitimate Coordinator, either:
     a. Setting a new manifest WITHOUT comparing the returned root
        CA certificate against the previously known-good one — the
        DEFAULT behavior of the contrast CLI, or
     b. Verifying the Coordinator without comparing its root CA
        certificate against a trusted, out-of-band reference
 
4. The workload owner is impersonated by the rogue Coordinator,
   which can now issue certificates, manage manifests, or otherwise
   act with the trust normally reserved for the legitimate Coordinator

Why This Matters for Confidential Computing

Contrast's entire value proposition rests on the Coordinator being a trusted root of verification for workload identity and secrets. A verification gap in the recovery path — combined with the CLI's default behavior of not comparing root CA certificates across manifest updates — means the standard, unmodified operator workflow is exposed to this attack whenever an adversary can achieve network redirection.

Impact Assessment

Recommendations

Immediate Actions

1. Upgrade to Contrast 1.4.1 or later to restore seed verification in the recovery flow.
2. Always compare the root CA certificate returned during manifest updates and Coordinator verification against a trusted, out-of-band reference — do not rely on the CLI's default behavior alone, even after patching.
3. Audit network paths to the Coordinator for any exposure to traffic redirection (DNS, ARP spoofing, compromised ingress/service mesh routing) and harden accordingly.
4. Review recent manifest changes for any Coordinator that may have been targeted during the affected window, and re-verify root CA continuity.

Defense-in-Depth

• Pin and independently verify the Coordinator's root CA certificate out-of-band (e.g. via a secure configuration management channel) rather than trusting whatever a manifest-update operation returns.
• Restrict network paths to the Coordinator to minimize opportunities for traffic redirection.
• Treat any workload-owner CLI operation against the Coordinator as security-sensitive and log/audit it accordingly.

References

• VulDB — CVE-2025-71426
• Contrast (Edgeless Systems)