]> Intra-handshake Attestation Considered Harmful (CVE-2026-33697 of CVSS 7.5) TU Dresden, Germany
muhammad_usama.sardar@tu-dresden.de
SEAT AI agents Intra-handshake attestation CVE-2026-33697 The draft aims to provide technical details of CVE-2026-33697 and EUVD-2026-16488, which is substantial technical evidence of how intra-handshake attestation fails in practice, even without phyical access. Moreover, since continuous attestation is required, intra-handshake attestation adds unnecessary complexity. The results are backed by the research and the ProVerif artifacts under Apache-2.0 license for reproducibility, and have been acknowledged by the relevant stakeholders. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .
Introduction This draft presents the formal specification and analysis of the candidate binding mechanisms for binding in intra-handshake attestation for standardization for attested TLS protocols: Binding mechanisms, implementations and ProVerif artifacts
No. Binding mechanism Used in Artifacts
1. Client’s TLS nonce Meta's AI binder1
2. Client’s attestation nonce - binder2
3. Early exporter - binder3
4. Server’s public key - binder4
5. Combination of #2 and #3 - binder5
6. Combination of #2 and #4 Edgeless Systems Contrast; Cocos AI; CCC Attestation SIG's adopted project intra-handshake attestation binder6
7. Combination of #2, #3, and #4 draft-fossati-tls-attestation-06 binder7
We responsibly disclosed the vulnerability in intra-handshake attestation -- as noted in security advisory issued -- to the vendors, which resulted in of CVSS 7.5.
Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Credits We discovered the vulnerability jointly with Viacheslav Dubeyko and Jean-Marie Jacquet.
Detailed Vulnerability Disclosure Timeline and Acknowledgements by Affected Vendors Detailed vulnerability disclosure timeline and acknowledgements
Event Date
Our initial responsible disclosure to vendor 07 Oct, 2025
Acknowledgement by vendor 14 Dec, 2025
Information to the IETF 11 Jan, 2026
Public announcement by vendor 27 Feb, 2026
Cocos AI published security advisory [Severity = HIGH (CVSS 7.8)] 23 March, 2026
CVE (CVE-2026-33697) published [Severity = HIGH (CVSS 7.5)] 26 March, 2026
Acknowledgment by Privasys for rustls CVE-2026-33697 [Severity = HIGH (CVSS 7.5)] 9 July, 2026
Acknowledgment by Privasys for go CVE-2026-33697 [Severity = HIGH (CVSS 7.5)] 10 July, 2026
CCC implementation declared vulnerable to relay attacks 17 July, 2026
Vulnerable CCC implementation repo archived 22 July, 2026
Vulnerable draft draft-fossati-tls-attestation withdrawn by authors 23 July, 2026
Edgeless Systems published security advisory [Severity = HIGH (CVSS 7.4)] 29 July, 2026
Comparison with Other Vulnerabilities in Confidential Computing Literature Severity is based on NIST metrics. Comparison with other vulnerabilities in confidential computing literature
Vulnerability CVE CVSS Severity
wiretap.fail No CVE (Intel and AMD announcements) - None
TEE.fail No CVE - None
TDXdown Intel 2.5 Low
Staleus CVE-2025-54509 4.0 Medium
BreakFAST CVE-2025-61972 4.2 Medium
BadRAM AMD 5.3 Medium
BreakFAST CVE-2025-61971 5.9 Medium
Fabricked CVE-2025-54510 5.9 Medium
Intra-handshake.fail CVE-2026-33697 7.5 High
The comparison of the above with CVSS 7.5 for indicates that attested TLS is not mature yet compared to the rest of the confidential computing stack, and is currently one of the weakest links in the ecosystem. Further formal analysis of production implementation of intra-handshake attestation has led to discovery of another class of attacks and will potentially lead to three CVEs (currently under responsible disclosure) each with an expected CVSS 9.1.
Vulnerable Implementations At least the following implementations are vulnerable:
  • Meta's AI: CVE-2026-33697 and EUVD-2026-16488 [Severity = HIGH (CVSS 7.5)]
  • Cocos AI: security advisory [Severity = HIGH (CVSS 7.8)], CVE-2026-33697 and EUVD-2026-16488 [Severity = HIGH (CVSS 7.5)]
  • Edgeless Systems Contrast: security advisory [Severity = HIGH (CVSS 7.4)]
  • CCC Attestation SIG's adopted project intra-handshake attestation: declared vulnerable to relay attacks and archived
  • Privasys rustls: Acknowledgment of applicability of CVE-2026-33697 [Severity = HIGH (CVSS 7.5)]
  • Pirvasys go: Acknowledgment of applicability of CVE-2026-33697 [Severity = HIGH (CVSS 7.5)]
If you are aware of any other intra-handshake attestation implementation, please let us know so that we can check and disclose the vulnerabilities to them.
Vulnerable Protocol Specifications At least the following protocol specifications with intra-handshake attestation path are vulnerable to CVE-2026-33697 and EUVD-2026-16488:
  • draft-fossati-seat-early-attestation
  • draft-ritz-seat-facts
  • draft-fossati-tls-attestation: withdrawn
Binding Levels
  1. DH shared secret (gxy) used as shared secret between client and server
  2. Handshake traffic key (htsc) used for encryption of handshake messages
  3. Application traffic key (astc) used for encryption of application data
Correlation Goals We consider TLS Server as RATS Attester, which is typical in confidential computing.
  1. Correlation of Evidence to a DH Shared Secret (G1)
  2. Correlation of Evidence to Client’s Handshake Traffic Key (G2)
  3. Correlation of Evidence to Client’s Application Traffic Key (G3)
Main Results
  • All analyzed binding mechanisms and the corresponding implementations of intra-handshake attestation are vulnerable to relay attacks.
  • Early exporter helps achieve level 1 binding.
  • Our proposed mechanism helps achieve level 2 binding.
  • It may not be possible to achieve level 3 in intra-handshake attestation alone without additional assumptions.
Main results
Property Mechanism #1,2,4,6 Mechanism #3,5,7 Proposed mechanism
G1 : Correlation of Evidence to gxy ❌ ✅ ✅
G2 : Correlation of Evidence to kch ❌ ❌ ✅
G3 : Correlation of Evidence to kc ❌ ❌ ❌
Expected Results Expected results
No. Binding mechanism Artifacts Expected results
1. Client’s TLS nonce binder1 binder1
2. Client’s attestation nonce binder2 binder2
3. Early exporter binder3 binder3
4. Server’s public key binder4 binder4
5. Combination of #2 and #3 binder5 binder5
6. Combination of #2 and #4 binder6 binder6
7. Combination of #2, #3, and #4 binder7 binder7
8. Proposed proposal proposal
Implications of Findings
Implications of Findings for IETF SEAT WG
  • We believe post-handshake attestation alone, such as draft-fossati-seat-expat, can achieve level 3 binding.
  • The research suggests that recent hybrid proposals (combination of intra-handshake attestation and post-handshake attestation) draft-fossati-seat-early-attestation and draft-ritz-seat-facts may add unnecessary complexity of intra-handshake attestation without adding any security benefit compared to post-handshake attestation alone, such as draft-fossati-seat-expat. We are not aware of any security property that hybrid proposals can achieve that post-handshake attestation alone cannot achieve.
  • The protocol specifications draft-fossati-seat-early-attestation and draft-ritz-seat-facts remain vulnerable to CVE-2026-33697.
Implications of Findings for IETF LAKE WG
  • Similar problems occur for protocol specification lake-ra.
Implications of Findings for IETF TLS WG
  • draft-fossati-tls-attestation-09 is vulnerable to CVE-2026-33697. Thankfully, the authors have withdrawn draft-fossati-tls-attestation-10.
  • Remote attestation within the handshake is very dangerous, since to our knowledge, it is one of the highest scored vulnerabilities in confidential computing literature (see ).
Implications of Findings for Agent2Agent From a security perspective, intra-handshake attestation does more damage than protection for AI agents.
Technical Details
Tool We use state-of-the-art symbolic security analysis tool ProVerif for the specification of the protocols.
Modeling The formal model uses the fixed version of diversion attacks in intra-handshake attestation from our previous work as the starting point to focus on relay attacks in intra-handshake attestation in this work. The rationale is that we consider it more useful to show the added value of this contribution to the community by using the fixed version of diversion attacks in intra-handshake attestation as the baseline, rather than showing the same diversion attacks from ID-Crisis paper, and the discovered CVE () -- which the previous analysis could not find -- practically demonstrates the added value. This modeling choice makes it clear that even with the diversion attacks fixed, high-severity relay attacks would still remain in intra-handshake attestation. Note: Similar to the fixed version of diversion attacks in intra-handshake attestation from our previous work, we model non-PSK-based handshake. From ID-Crisis paper:
  • For modeling TLS 1.3, we consider handshakes based on Diffie-Hellman over either finite fields or elliptic curves, represented as (EC)DHE. This is because we are unaware of any publicly available specification or implementation of attested TLS with PSK-based handshakes.
While it would be nice to model PSK-based handshake, the rationale is that the correlation properties studied in this work do not necessarily require it.
Technical Report Technical report is available at . It is accepted for publication at ESORICS 2026.
Artifacts Artifacts are available at under Apache-2.0 License.
Media Coverage Several media enthusiasts have covered the vulnerabilities to protect the community from the harm of intra-handshake attestation.
  • The Register
  • (Japanese) BlackHatNewsTokyo
  • (Several languages) Hackernoon
  • Apple podcast
  • Information Security News
  • TheNextGenTechInsider
  • DailySecurityReview
  • SC World
  • 01 Quantum
  • (Russian) Security Lab
  • (German) blogspan
  • (Chinese) Sina
  • data4biz
  • (Russian) ITSec
  • (Chinese) smzdm
  • (Chinese) donews
  • (Chinese) ifeng
  • dugganusa
  • dugganusa repo
  • spoitus
  • lavx news
  • sohu
  • (Persian) news.ditty
  • (Russian) LiMP VPN
  • daily.dev
  • warden
  • GCVE.eu
  • coderlegion
  • freenode
  • (Chinese) csdn
  • osintsights
  • (Turkish) hardwaremania
  • akber
  • ad-hoc news
  • AIMultiple
If you have written an article on this and would like to be added here, please send us a PR or an email with the subject "media coverage of intra-handshake.fail"
Security Researchers Credible security researchers, such as the following, have publicly attested to it.
  • Michael Pak
  • Rodrigo Branco
  • Bart Preneel
  • Thorsten Strufe
Germany's BSI Germany's Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik) has attested to it. Carina Hilt, deputy press spokesperson at BSI, told The Register:
Reviews
Conference Reviews has been peer-reviewed and accepted for publication at ESORICS 2026.
IETF/IRTF Several participants of the IETF/IRTF have attested to the results by independently verifying the code. Some of the participants have independently reproduced the results by developing their own formal models and a proof-of-concept implementation of the vulnerabilities. Some of the messages are mentioned below:
  • https://mailarchive.ietf.org/arch/msg/seat/aEV9dUFotAQzHndk23qBcwBT3as/
  • https://mailarchive.ietf.org/arch/msg/seat/3Hv0E1sfXsvyBtl6AgY8j-SHHiw/
  • https://mailarchive.ietf.org/arch/msg/seat/JF_cwmHHEbrJ_W5V6yEetWWnii4/
  • https://mailarchive.ietf.org/arch/msg/seat/5LJ6i9svomnhpyPHWPejM7fMmXQ/
  • https://mailarchive.ietf.org/arch/msg/seat/P_CYTycg0KG7cbKauFA-kVgX2jo/
  • https://mailarchive.ietf.org/arch/msg/seat/ZJjJXpYwZ5nCVmz_W4FK6XiFEY4/
  • https://mailarchive.ietf.org/arch/msg/seat/Q6Jmc58v0c1lDV3ujIY0AX_ofGA/
  • https://mailarchive.ietf.org/arch/msg/seat/beRzNNvwMifkRfJPfxecGoHpTDs/
  • https://mailarchive.ietf.org/arch/msg/cfrg/U5YHd91lYjiqCTt9BZyVDNFeUpM/
  • https://mailarchive.ietf.org/arch/msg/seat/aFCo4BMRDSUynvN9AQJatPjnXag/
  • https://mailarchive.ietf.org/arch/msg/seat/wb_Ys9MZd9u9oM2Bk-8tv7fvXGg/
  • https://mailarchive.ietf.org/arch/msg/seat/ov8f-7cZKK5RZ-Mmjc6IhVSB-Fk/
  • https://mailarchive.ietf.org/arch/msg/seat/2uUuaD1DygjNDM4GT_-rYbwTiJk/
  • https://mailarchive.ietf.org/arch/msg/seat/2_aGylmFHoLmqN7BBcYVoH-rNJk/
  • https://mailarchive.ietf.org/arch/msg/seat/VyifG8zP5aworb_S1NR9FEUEXW0/
  • https://mailarchive.ietf.org/arch/msg/seat/CYwvM75z6rTId2A3ZZvZJmHxOig/
  • https://mailarchive.ietf.org/arch/msg/ufmrg/29xFZX5C4oSGkpZAvXT_7YLW2Vc/
  • https://mailarchive.ietf.org/arch/msg/seat/u1HxYW9cJfVpi3Cf9q06ehwpYGE/
  • https://mailarchive.ietf.org/arch/msg/seat/SG_A0016a-KMnXAkGtMUxokZmjc/
  • https://mailarchive.ietf.org/arch/msg/seat/3w7-OW2CAVr0-QBz97eAMxB_nMI/
In short, three main questions have been raised by WG participants in support of our work:
  • What security property hybrid (intra- + post-handshake attestation) provides that post-handshake attestation alone cannot provide?
  • Since continuous attestation is required in most use cases, how is additional complexity of intra-handshake attestation justified? Use cases with one-time attestation can be covered by doing attestation round immediately after Connection Establishment Time: see reference.
  • What is the benefit of doing signatures of remote attestation within the handshake (as this latency can be exploited)? See reference.
Researchers outside of IETF/IRTF Some researchers have approached us confirming the proof-of-concept of the vulnerabilities in intra-handshake attestation. More information will be added once their pre-prints/papers are public.
Security Considerations All of this document is about the insecurity of intra-handshake attestation.
IANA Considerations This document has no IANA actions.
References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Intra-handshake.fail (CVE-2026-33697): High-severity CVE in Attested TLS Intra-handshake.fail (CVE-2026-33697): High-severity CVE in Attested TLS CoCoS attested TLS is vulnerable to relay attacks via extracted ephemeral TLS keys CVE
Acknowledgments We would like to thank our co-authors of paper for their valuable contributions:
  • Viacheslav Dubeyko
  • Jean-Marie Jacquet
We gratefully acknowledge the following for insightful discussions and reviews on this work:
  • Eric Rescorla
  • Juho Forsén
  • Markus Rudy
  • Mariam Moustafa
  • Bruno Blanchet
  • Steve Kremer
  • Tjaden Hess
  • Martin Thomson
  • Yuning Jiang
  • Pavel Nikonorov
  • Casey Wilson
  • Danko Miladinovic
  • Songbo Bu
  • John Preuß Mattsson
  • Werner Staub
  • Haowen Song
  • Chengxin Huang
  • Steve Luo
  • Kubilay Ahmet Küçük
  • Patrick Duggan
  • Nathanael Ritz
  • Deb Cooley
We also gratefully acknowledge the following who gave feedback on previous state-of-the-art that we utilize as the basis:
  • Tuomas Aura
  • Ionut Mihalcea
  • Thomas Fossati
  • Hannes Tschofenig
  • Yaron Sheffer
  • Laurence Lundblade
  • Giridhar Mandyam
  • Christopher Patton
  • Jonathan Hoyland
  • Richard Barnes
Several others at the IETF, IRTF, CCC, and GA4GH have contributed by providing feedback. We sincerely thank Karthikeyan Bhargavan, Bruno Blanchet, and Nadim Kobeissi for the foundational formal model of draft 20 of TLS 1.3 in their work. The research work is funded by German Research Foundation ("Deutsche Forschungsgemeinschaft.")