Researchers at TU Dresden disclosed a fundamental design flaw in the cryptographic mechanism used to prove that a server is running code inside a genuine Trusted Execution Environment, demonstrating that the attestation process can be silently bypassed by an attacker who relays a client connection to a different, attacker-controlled server without the client detecting any deviation. The vulnerability has been assigned CVE-2026-33697 with a CVSS score of 7.5 and affects implementations across a broad cross-section of the confidential computing ecosystem, including Meta’s WhatsApp Private Processing system, Edgeless Systems’ Contrast platform, Cocos AI versions 0.4.0 through 0.8.2, and the Confidential Computing Consortium’s reference proof-of-concept.
How the CVE-2026-33697 Relay Attack Bypasses Attested TLS Verification
Confidential computing relies on a mechanism called attested TLS to prove to a client that the server handling its data is running inside a genuine hardware enclave — an isolated computing environment where the host machine operator cannot inspect or tamper with the computation. Meta’s WhatsApp, for instance, used this mechanism to offer privacy guarantees for its AI features, asserting that even Meta’s own server operators could not observe AI message analysis.
The research, presented by Muhammad Usama Sardar of TU Dresden along with co-authors Mariam Moustafa and Tuomas Aura at the AsiaCCS 2026 conference, shows that this proof mechanism falls short at a critical step in the handshake. Current attested TLS implementations achieve what the researchers call “binding level one” — linking the attestation evidence to the initial key exchange in the TLS handshake. What they do not achieve is “binding level two,” which would link the attestation to the identity confirmation step that follows.
How an Attacker Exploits the Binding Gap in TLS Attestation
The practical attack works as follows: an adversary positioned to intercept TLS handshakes — through a network-level interception point or a compromised infrastructure node — relays the client’s connection to a separate attacker-controlled server that also runs the same attested software inside a valid TEE. Because the attestation only proves that some server with the expected software configuration is present somewhere in the connection, the client cannot distinguish a direct connection from a relayed one. Both ends of the relay hold valid attestations; the client has no way to confirm it is communicating with the intended server rather than an attacker-controlled relay.
Meta WhatsApp Private Processing and the Affected Confidential Computing Implementations
Meta’s WhatsApp Private Processing system was one of the implementations identified as affected. WhatsApp introduced Private Processing to support AI features while assuring users that message content was processed in confidential computing enclaves where even Meta could not observe the data. The CVE-2026-33697 relay attack undermines that assurance by demonstrating that the connection could be silently redirected to a server under an attacker’s control without the client detecting the deviation, even when both servers run the same software in valid TEE hardware.
Additional affected implementations include Edgeless Systems’ Contrast confidential computing platform and Cocos AI in versions 0.4.0 through 0.8.2. The Confidential Computing Consortium’s own reference proof-of-concept implementation, which serves as a baseline for the broader ecosystem, also carries the flaw. The breadth of affected implementations reflects how foundational the vulnerable design is to the current attested TLS architecture rather than a defect in any single vendor’s code.
Why No Comprehensive Fix for CVE-2026-33697 Currently Exists
The researchers do not describe the relay vulnerability as a coding error that can be resolved with a patch. Their analysis concludes that achieving “binding level three” — the security level that would fully prevent relay attacks — may be fundamentally unachievable within the intra-handshake attestation architecture that the current protocol generation uses. The working group convened to address the issue has recommended abandoning intra-handshake attestation entirely in favor of post-handshake approaches, which represents an architectural redesign rather than an incremental fix.
The Intra-Handshake Attestation Architecture Problem and the Post-Handshake Alternative
The core issue is that intra-handshake attestation, where the TEE proof is embedded within the TLS handshake itself, cannot cryptographically bind that proof to the specific end-to-end path of the connection at the identity confirmation stage. Post-handshake attestation approaches, where the TEE proof is delivered after the encrypted channel is fully established, offer a path to addressing the binding problem but require changes to how clients and servers negotiate trust in the first place. Until a revised architectural standard is adopted and implementations are updated, deployed confidential computing systems relying on current attested TLS designs cannot fully guarantee that client connections are reaching the intended server.
Cloud providers including AWS, Azure, and Google Cloud market confidential computing services to customers processing sensitive data who want cryptographic assurance that the provider’s own operators cannot observe computations. CVE-2026-33697 affects the underlying trust claim that makes those guarantees meaningful, and organizations that have deployed confidential computing specifically for that privacy assurance should evaluate their implementations against the affected versions and monitor for guidance from their providers on architectural migration paths.
