Security protocols are designed to protect communication between systems. But history has shown that adding more security mechanisms does not always result in stronger security. If those mechanisms are not carefully designed, they can introduce entirely new attack surfaces.
A recently published IETF Internet-Draft analyzes CVE-2026-33697, a vulnerability affecting intra-handshake attestation in Attested TLS. Through formal verification, practical analysis, and real-world implementation evidence, the researchers show that the current approach remains vulnerable to relay attacks while introducing additional protocol complexity.
According to the authors, this vulnerability carries a CVSS score of 7.5 (High) and is, to the best of their knowledge, the highest-scoring vulnerability reported in the published literature of Confidential Computing.
Let's look at what this vulnerability is, why it matters, and what lessons it offers for the future of secure protocol design.
What Is Intra-Handshake Attestation?
Confidential computing allows applications to execute inside Trusted Execution Environments (TEEs), protecting sensitive workloads even from privileged system software.
Before communicating with such an environment, clients typically perform remote attestation, which verifies that the remote system is running trusted hardware and expected software.
One proposed approach performs this verification during the TLS handshake, before encrypted communication begins. This technique is known as intra-handshake attestation.
The objective is to tightly bind the attestation evidence to the TLS connection so that clients know they are communicating with the intended trusted environment.
On paper, this appears to strengthen security.
The research behind CVE-2026-33697 demonstrates that the reality is more complicated.
The Core Security Problem
A useful way to understand the vulnerability is through the intuition shared by the researchers:
A client may believe it has established a secure connection with the intended trusted machine, while the connection can actually be relayed to a completely different machine.
In other words, the attestation is not strongly bound to the actual communication session.
This opens the possibility of relay attacks, where attackers forward messages between systems while preserving apparently valid attestation evidence.
Although the client receives valid cryptographic proofs, those proofs do not necessarily guarantee that application traffic is reaching the trusted machine the client intended to communicate with.
How Was the Vulnerability Discovered?
Rather than relying solely on manual reasoning, the researchers used ProVerif, a formal verification tool widely used to analyze cryptographic protocols.
Formal verification allows protocol designs to be mathematically analyzed under well-defined security models, making it possible to discover subtle flaws that may not appear during ordinary testing.
After analyzing several proposed attestation-binding mechanisms, the researchers found that every evaluated intra-handshake binding approach remained vulnerable to relay attacks.
Their conclusion was that intra-handshake attestation alone cannot provide the strongest security guarantees for protecting application traffic.
Vendor Acknowledgement
One of the strongest aspects of this disclosure is that the issue is not merely theoretical.
According to the Internet-Draft, the affected vendors acknowledged the vulnerability and published security advisories for impacted implementations.
Vendor acknowledgement provides additional confidence that the issue represents a practical security concern rather than only an academic observation.
Why CVE-2026-33697 Is Significant
The vulnerability has been assigned CVE-2026-33697 with a CVSS score of 7.5 (High).
Beyond the CVSS rating itself, the authors note that this is the highest CVSS score reported in the published literature of Confidential Computing to date.
Many previous Confidential Computing vulnerabilities affected hardware, firmware, or Trusted Execution Environments. In contrast, CVE-2026-33697 targets the protocol layer responsible for securely binding remote attestation to encrypted communication, exposing weaknesses in how trust is established rather than how it is enforced by hardware.
This highlights that even when trusted hardware behaves correctly, protocol design mistakes can still undermine overall system security.
Affected Implementations
The draft also documents multiple affected implementations together with supporting evidence.
Examples discussed by the authors include:
- Meta's Private Processing for WhatsApp
- Edgeless Systems Contrast
- Cocos AI
- The Confidential Computing Consortium (CCC) Attestation SIG's adopted project
The presence of affected production implementations demonstrates that the research extends beyond academic protocol models and has practical implications for existing deployments.
Implications for Future Standards
The impact of this research goes beyond today's implementations.
According to the draft, several ongoing IETF proposals based on intra-handshake attestation inherit similar security concerns.
This means the findings influence not only deployed software but also the future direction of standardization efforts for Attested TLS.
Identifying these weaknesses before protocols become widely standardized gives the community an opportunity to improve future designs and avoid embedding insecure assumptions into long-term Internet standards.
Recommended Direction
Instead of performing attestation during the TLS handshake, the authors recommend post-handshake attestation.
Separating attestation from the handshake simplifies protocol design while providing stronger binding between attestation results and subsequent application traffic.
The recommendation illustrates an important principle in security engineering:
A simpler protocol that is formally verified is often more secure than a more complex protocol with additional features.
Why This Matters
Modern cloud platforms increasingly rely on confidential computing to protect sensitive workloads.
As these technologies become more widely deployed, ensuring that remote attestation protocols are both secure and practical becomes increasingly important.
CVE-2026-33697 serves as an example of why formal verification should be an essential part of protocol design. By mathematically analyzing security properties before widespread deployment, researchers can identify weaknesses that traditional testing may overlook.
The work also reminds us that stronger security is not achieved by simply adding more protocol steps. Security depends on choosing designs that are both correct and verifiable.
Final Thoughts
CVE-2026-33697 shows that even carefully designed security protocols can contain subtle weaknesses.
Through formal verification, implementation analysis, vendor acknowledgements, and practical evidence, the researchers demonstrate that intra-handshake attestation introduces complexity without providing the strongest security guarantees against relay attacks.
The research not only documents an important vulnerability but also offers guidance for improving future attestation protocols and Internet standards.
As Confidential Computing continues to evolve, work like this helps ensure that future protocols are built on designs that are both simpler and more secure.
Further Reading
If you'd like to explore the research in more detail, the following resources provide the complete technical analysis, formal verification models, implementation evidence, and proposed improvements.
These resources include the formal proofs, proof-of-concept models, affected implementations, security analysis, and discussion of future protocol directions surrounding CVE-2026-33697.
