Description

Contrast before 1.16.0 is susceptible to remote attestation relay attacks. Contrast accepted any TEE attestation report that verified correctly and contained the expected firmware patch levels and software measurements, regardless of which machine produced it, so attestation was not bound to specific, physically trusted hardware. An attacker who can both intercept network traffic between the CLI and the Coordinator (or between the Coordinator and an attested component) and forge reports or extract secrets from any single TEE machine under their physical control can relay such a report to impersonate a Contrast Coordinator or a Contrast workload, defeating identity verification in Contrast's attested TLS (aTLS).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-09-27T02:17:21.640Z",
  "pubdate": "2026-09-27T02:17:21.640Z",
  "executiveSummary": "Contrast versions prior to 1.16.0 contain a critical vulnerability involving improper validation of Trusted Execution Environment (TEE) attestation reports. The security flaw stems from a lack of cryptographic binding between the attestation report and the specific hardware instance, enabling remote attestation relay attacks. By intercepting communication between the CLI and the Coordinator, or between the Coordinator and attested components, an attacker can leverage a compromised TEE machine under their physical control to forge or replay valid, legitimate attestation reports. This vulnerability effectively undermines the integrity of Contrast's attested TLS (aTLS) implementation. Successful exploitation allows an unauthorized actor to impersonate either a Contrast Coordinator or a valid workload, bypassing identity verification protocols. The risk is significant, as it permits attackers to intercept, manipulate, or inject traffic within environments that rely on TEE-backed security guarantees. An attacker requires the capability to intercept network traffic and control a TEE-enabled machine to perform this relay attack, effectively negating the trust established by the hardware-based attestation mechanism.",
  "technicalDetails": "The vulnerability resides in the attestation verification logic of Contrast prior to version 1.16.0. The root cause is the failure to enforce binding between the attestation report and the unique hardware identity (such as specific public keys or hardware-bound identifiers) of the entity being verified. While the system correctly validates the integrity, firmware patch levels, and software measurements of a provided TEE attestation report, it does not ensure that the report originated from the specific expected machine.\nIn a secure TEE-based architecture, remote attestation is intended to prove that a piece of software is running on authentic, untampered hardware. Because Contrast's implementation accepted any valid attestation report that met the defined software and firmware criteria, it became susceptible to relay-based impersonation. An attacker in possession of a TEE-capable device can generate a legitimate attestation report that satisfies all the Coordinator's policy requirements.\nThe attack flow proceeds as follows: First, the attacker positions themselves as a Man-in-the-Middle (MitM) between the CLI and the Coordinator or between two attested components. Second, the attacker captures an attestation request directed at a legitimate workload. Third, the attacker provides an attestation report generated from their own physically controlled, yet authentic, TEE machine. Because the Coordinator only checks if the report is cryptographically valid and contains the expected measurements (ignoring the specific device origin), it accepts the attacker's report as genuine.\nBy successfully relaying this report, the attacker establishes a trusted aTLS session, effectively impersonating the target Coordinator or workload. This allows the attacker to decrypt or manipulate the subsequent encrypted traffic, defeating the primary security purpose of the attested TLS connection. The vulnerability relies on the attacker's ability to intercept network traffic and access a TEE device. There are no privilege requirements on the target system itself, as the bypass occurs during the authentication handshake process. Post-exploitation, the attacker gains the ability to impersonate secure entities, leading to full compromise of the communication channel and unauthorized access to potentially sensitive data or control instructions transmitted through the aTLS tunnel."
}