Confidential computing sells a simple promise: before sensitive data goes anywhere, the client can cryptographically verify it is talking to a genuine, unmodified Trusted Execution Environment (TEE). New research says the promise is only partially true, and in ways that matter. A protocol used for that verification, “attested TLS,” can be abused so a connection intended for one server is silently redirected to a different, compromised machine that runs identical software, without the client noticing.

The gap comes from where the attestation evidence is bound. Sardar, a researcher at TU Dresden, spent two years formally verifying attested TLS using ProVerif and found diversion attacks against two state-of-the-art attested TLS protocols. His later work goes further on “intra-handshake attestation,” where evidence is generated during the TLS handshake itself. It tested seven cryptographic binding methods and concluded none prevent relay attacks, where the client verifies evidence about a genuine, trustworthy AI agent or server but ends up encrypting its traffic to an entirely different, malicious one.

This is why confidential computing executives should care, even if their threat model is “we trust the hardware.” In confidential computing, the root of trust is the hardware manufacturer. Sardar put it bluntly: “There is absolutely no way around this.” The industry, including Intel and Google Cloud, positions TEEs and related assurances as the backbone of secure, auditable processing. Intel product pages say TDX will “add safeguards to data sovereignty and governance.” Google Cloud describes confidential computing infrastructure as offering “full, auditable control over access to customer data.” What the new research stresses is that the attestation layer is supposed to do the heavy lifting after that hardware root of trust is accepted. In his findings, it does far less than assumed.

The most important technical nuance is also the most executive-friendly: there are different “levels” of trust, depending on what exactly attestation evidence is cryptographically tied to. The researchers formalize the problem as three increasingly strict levels of binding between attestation evidence and the TLS connection it is meant to vouch for.

Level one binds evidence only to the very first key exchange in the handshake, the Diffie-Hellman step, where client and server agree on a shared secret before either side has proven identity. Level two binds evidence to the client’s handshake traffic key, covering everything up to the server’s identity confirmation. Level three binds evidence to the application traffic key itself, the key used to actually encrypt sensitive data once the connection is live.

Sardar’s analysis focused on intra-handshake attestation, and post-handshake attestation fell outside that scope. Under those conditions, three of the seven binding mechanisms achieve only level one. The rest fail even that baseline. The strongest takeaway is level three: the paper concludes it “may not be possible” within intra-handshake attestation as currently architected without breaking TLS 1.3 properties that the protocol was never designed to give up.

So what does “best fix available today” mean in practice? Sardar’s team proposed a “cryptographic binder” built from the TLS handshake secret combined with the server’s public key, and it formally achieves level two. In plain terms, that improvement helps prove the client is talking to the right machine at the start of a handshake. It does not prove that minutes later, the data being encrypted is still destined for that same machine. For boards and security leaders, that is the difference between “secure channel with assumptions” and “secure channel with evidence that follows the data.”

And this is not only a lab curiosity. The researchers formally analyzed four real-world implementations of intra-handshake attestation. These include Meta’s Private Processing system for WhatsApp, Edgeless Systems’ Contrast, the open-source Cocos AI platform, and a proof-of-concept maintained by the Confidential Computing Consortium’s (CCC) Attestation Special Interest Group. The first three are running in production. The attacks apply to every version of Cocos AI between 0.4.0 and 0.8.2.

The reporting also includes a detail that should change how risk teams think about “security reviews.” The class of flaw is not new, and it can be subtle enough to go undiscovered for years before formal analysis catches it. Responsible disclosure resulted in CVE-2026-33697, rated 7.5 on the Common Vulnerability Scoring System (high severity). For comparison, the researchers cite BadRAM, the 2024 memory aliasing attack against AMD’s SEV-SNP that made headlines, scoring 5.3. The CCC Attestation SIG repository lists CVE-2026-33697 as the highest-scoring vulnerability among a cluster of recent confidential computing flaws, ahead of Fabricked (5.9), BreakFAST (5.9), and Staleus (4.0).

Here is the governance and methodology kicker. Both the CCC working group and the IETF’s TLS working group formally acknowledged relay attacks, and Sardar told The Register that “As implemented today, attested TLS is not mature yet,” adding that they are investigating further and expect more issues. Meta commissioned an extensive security review of its WhatsApp implementation from Trail of Bits, but that review did not detect the relay attack. The reason, according to the paper’s record, is not incompetence. Trail of Bits confirmed that no formal methods were used, while tools like ProVerif can exhaustively check a protocol against every scenario in a defined threat model. Manual audits sample; formal verification enumerates.

That leads to a process story with real-world consequences. The vulnerability itself went through orderly disclosure, flagged to Cocos AI in October 2025, acknowledged two months later, and published as CVE in March 2026. Then, in June, Sardar asked the CCC Attestation SIG to publish a new public GitHub repository named relay-attacks-in-intra-handshake under an Apache 2.0 license, so researchers and the standardization community could use the formal analysis artifacts. It is the kind of administrative step that should take minutes, yet the source indicates it did not happen on that timeline, with Sardar following up on 14 June and again three days later.

For executives, the strategic stake is simple and uncomfortable: confidential computing can still fail at the moment you most need proof, the moment where “trusted hardware” is supposed to guarantee that encrypted traffic stays locked to the right target. If your roadmap, compliance story, or customer promises lean on attested TLS as the cryptographic backbone, this research is a warning sign. It suggests that what you assumed was mature evidence of identity during the handshake may not provide the binding you think it does, and that the “fix” may require architectural shifts beyond what intra-handshake attestation can currently guarantee.