CVE-2026-33697 — a high-severity flaw rated 7.5 — captures the core finding: the cryptographic machinery meant to prove where confidential workloads run can be tricked into vouching for the wrong machine.
How attested TLS and intra-handshake attestation fail
Researchers led by Muhammad Usama Sardar at TU Dresden used ProVerif, a formal verification tool, to test whether attested TLS — the protocol family that ties Trusted Execution Environment (TEE) evidence into TLS handshakes — actually guarantees that a client’s sensitive data reaches the intended server. Their papers, Identity Crisis in Confidential Computing (with Mariam Moustafa and Tuomas Aura) and Intra-handshake.fail (with Viacheslav Dubeyko and Jean‑Marie Jacquet), present exhaustively modelled attacks.
The team formalised three levels of binding between attestation evidence and the connection: level one binds only to the initial Diffie‑Hellman exchange, level two binds to the client's handshake traffic key, and level three binds to the application traffic key used to encrypt live data. Three of seven examined binding mechanisms only achieve level one; the rest fail that baseline. Sardar’s proposed mitigation — a cryptographic binder built from the TLS handshake secret combined with the server's public key — achieves level two formally. Level three, the one that would prove a connection remains bound to the attested machine for the lifetime of the session, "may not be possible" within current intra-handshake attestation architectures without altering core properties of TLS 1.3. The practical result: a client can complete attestation against a genuine, unmodified TEE and yet have its traffic silently relayed to a compromised machine running identical software, anywhere in the world, without detecting the switch.
Production systems shown vulnerable: Meta, Edgeless Systems, Cocos AI, CCC proof-of-concept
The analysis was not theoretical only. Sardar’s team formally analysed four real-world implementations of intra-handshake attestation: 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 responsible-disclosure process led to CVE-2026-33697, rated 7.5. The paper’s authors note that the severity surpasses several recent confidential-computing issues listed by the CCC Attestation SIG — CVE-2026-33697 is the highest-scoring entry among a cluster that includes Fabricked (5.9), BreakFAST (5.9) and Staleus (4.0). The team also points out that the class of flaw is subtle and could remain undiscovered by sampled manual audits; Trail of Bits’ pre-existing review of Meta’s WhatsApp implementation, for example, did not detect the relay attack because no formal methods were used, the ESORICS paper records.
Standards bodies, government assessors, and vendors respond
Institutional responses split along procedural lines. The IETF’s Secure Evidence and Attestation Transport (SEAT) working group wrote Sardar’s correlation properties into its charter as an explicit, mandatory requirement for new specifications. The IETF TLS working group formally acknowledged the relay attacks but did not adopt a binding requirement. The CCC Attestation SIG acknowledged the vulnerability in its own repository but, according to Sardar, delayed creating a dedicated artefact repository; Sardar ultimately published his analysis inside an existing CCC‑affiliated repository.
Germany’s Federal Office for Information Security (BSI) reached a related conclusion independently. Deputy press spokesperson Carina Hilt told The Register that confidential computing (CC) functions as "a defense-in-depth component" that strengthens tenant isolation, confidentiality and integrity, but not availability, and that "dependencies on other services, such as identity and key management etc., are also not mitigated by CC." Hilt added that "The vendors' positioning on CC might give too much weight to its technical capabilities" and that "CC alone cannot satisfy the requirements for digital sovereignty."
Vendors responded selectively. Mikael Moreau, Intel’s France Communication Manager, said Intel "does not consider its attestation infrastructure to be a limitation to sovereignty guarantees," arguing any reliance on Intel silicon and its certificate root of trust is "bounded" and that customers or independent verifiers can make operational trust decisions. Intel did not answer a direct question about whether its attestation infrastructure poses a sovereignty risk under RISAA. Google did not respond to requests for comment for this article.
What this means for security teams, BSI, and European CIOs
- Security teams and implementers: The finding underscores the limits of sampled manual audits. Sardar’s group recommends abandoning intra-handshake attestation in favour of post-handshake attestation to achieve level three binding, and their mitigation achieves only level two within the existing intra-handshake model.
- BSI and other regulators: BSI’s independent assessment echoes the protocol finding: confidential computing is a defensive layer, not a standalone sovereignty solution. Regulators should treat attestation claims as dependent on identity and key-management infrastructures that confidential computing does not eliminate.
- European CIOs and procurement officers: Vendor marketing that ties confidential computing to "sovereign" guarantees must be weighed against the protocol limits Sardar’s analysis exposes — specifically, whether the attestation evidence can cryptographically bind to the application traffic key and the operational identity services a deployment uses.
Disclosure friction and the practical question left open
The vulnerability followed an orderly notification to vendors and a CVE publication in March 2026, but the process became contentious when Sardar requested on 14 June a public GitHub repository named relay-attacks-in-intra-handshake from the CCC Attestation SIG. After reminders on 17 June, 18 June and 24 June, the repository still did not exist; Sardar then published the artefacts in an existing CCC-affiliated repository so the community could access them. The CVE and the mathematics stand regardless.
What remains stark is the practical policy question the researchers and Germany’s BSI both raise: if attestation as implemented today cannot cryptographically bind evidence to the key that protects live application data, how much weight can buyers and regulators place on confidential computing when assessing digital sovereignty claims? Sardar’s blunt recommendation to the IETF TLS working group is to abandon intra-handshake attestation; where standards, vendors and procurers go from here will determine whether confidential computing is a legitimate sovereignty tool or only an architectural promise with important, practical gaps.
