Confidential Computing Security Protocols Face Critical Vulnerability

Confidential computing, a technology marketed as the bedrock of sovereign cloud infrastructure, contains a fundamental architectural flaw in its remote attestation protocols. New research indicates that these protocols, which are intended to cryptographically verify the integrity of a Trusted Execution Environment (TEE), fail to prevent sophisticated relay attacks. These vulnerabilities allow attackers to redirect secure connections to malicious hardware, even when the software integrity remains verified.

What is the vulnerability in attested TLS?

The security gap centers on “attested TLS,” a protocol designed to prove to a client that a server is running within a genuine, unmodified TEE. According to research conducted by Muhammad Usama Sardar at TU Dresden, these protocols verify software integrity but fail to verify the physical location of the server. In a series of relay attacks, a client’s encrypted traffic can be silently redirected to a compromised machine running identical software elsewhere. This means that while a client confirms they are talking to a “trusted” software environment, they are actually transmitting sensitive data to an unauthorized destination.

How do relay attacks bypass current protections?

The research, presented at the AsiaCCS 2026 conference and further detailed in a paper accepted for ESORICS 2026, demonstrates that current “intra-handshake” attestation mechanisms are insufficient. Sardar and his co-authors tested seven different ways of binding attestation evidence to TLS connections and found that none successfully prevent relay attacks. The fundamental issue is one of cryptographic binding: the attestation evidence is often generated too early in the handshake process to be securely bound to the application traffic keys used to encrypt data later. As the researchers noted, achieving “level three” binding—the strongest form—may be impossible without fundamentally altering the TLS 1.3 protocol.

Which production systems are affected?

This is not merely a theoretical concern. Formal analysis confirmed that the vulnerability exists in several production systems, including Meta’s Private Processing system for WhatsApp, Edgeless Systems’ Contrast, and the open-source Cocos AI platform. The vulnerability is tracked as CVE-2026-33697, with a high-severity score of 7.5 on the Common Vulnerability Scoring System (CVSS). For context, this is a higher severity rating than the 2024 “BadRAM” memory aliasing attack against AMD’s SEV-SNP. The IETF’s TLS working group and the Confidential Computing Consortium (CCC) have both formally acknowledged the existence of these relay attacks.

Does confidential computing guarantee digital sovereignty?

The findings have prompted scrutiny regarding the marketing claims surrounding confidential computing. Germany’s Federal Office for Information Security (BSI) has stated that while confidential computing strengthens tenant isolation, it does not mitigate dependencies on external identity and key management services. A BSI spokesperson noted that vendor positioning may place “too much weight” on technical capabilities, emphasizing that the technology alone cannot satisfy the requirements for digital sovereignty. Furthermore, while companies like Intel maintain that their attestation infrastructure is “bounded” and independent of customer workload data, they have not clarified whether their systems pose risks under legal frameworks such as the 2024 US RISAA law, which can compel hardware manufacturers to cooperate with intelligence orders.

Key Takeaways

• Protocol Flaw: Attested TLS protocols verify software integrity but fail to verify physical location, enabling relay attacks.
• High Severity: CVE-2026-33697, a high-severity flaw, affects multiple production-grade confidential computing implementations.
• Binding Limitations: Current “intra-handshake” attestation cannot reliably bind evidence to the final application traffic keys.
• Regulatory Outlook: National security bodies, including Germany’s BSI, warn that confidential computing is not a complete solution for digital sovereignty.

Moving forward, the IETF’s Secure Evidence and Attestation Transport (SEAT) working group has incorporated correlation properties as a mandatory requirement for new specifications. Meanwhile, researchers recommend that developers abandon intra-handshake attestation in favor of post-handshake approaches, which allow for more robust cryptographic binding once the final application keys are established.