EUVD-2026-104535
GHSA-hqrh-qq2r-6h96
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain extracted attested-TLS private key
-
DeliveryRelay relying party's nonce to genuine attester
-
ExploitReplay valid Evidence in attacker's handshake
-
ExecutionImpersonate attested workload
-
ImpactIntercept confidential session data
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Origin validation
|
| Exploitation Conditions | Exploitation requires three concrete conditions drawn from the description: (1) the attacker must possess an extracted attested-TLS private key for the target; (2) the attacker must be able to relay/MITM between the relying party and a genuine attester to forward the relying party's attestation nonce and replay the returned Evidence; and (3) the target must run the attested-tls-poc implementation using binding mechanism #6 (combination of attestation nonce and server public key), which the formal analysis shows satisfies none of the correlation goals G1-G3. Limiting factors: high attack complexity (AC:H) and a present attack requirement (AT:P) reflecting the need to control a private key and sit on the relay path; impact is confined to this proof-of-concept rather than a production TLS stack, and the maintainers have already published guidance not to deploy it. |
| Impact | Signals conflict on real-world priority. The input CVSS 4.0 base score is 9.1 (Critical) with network vector and no privileges/UI, and the issue is backed by publicly available exploit code (VulnCheck PoC, PR #58 and the relay-attacks-formal artifacts) plus a vendor fix, which raises nominal severity. However, several factors deflate real risk: the CVSS vector itself carries AC:H (high complexity) and AT:P (a present attack requirement), and the description's core precondition is that the attacker already holds an extracted attested-TLS private key and can relay the relying party's nonce to a genuine attester - a substantial prerequisite. There is no EPSS score and no CISA KEV listing in the input, so exploitation status is 'publicly available exploit code exists' - not confirmed active exploitation; POC availability must not be read as in-the-wild use. Most importantly, the affected product is itself a proof-of-concept (attested-tls-poc) that the maintainers explicitly marked 'do NOT use' after formal analysis, so widespread production exposure is unlikely. Data note: the description cites CVE-2026-112377 while all referenced artifacts and the ESORICS paper describe this flaw as CVE-2026-33697 ('Intra-handshake.fail') - verify the correct CVE identifier with the CNA before cross-referencing. |
| Exploit ScenarioDerived | An attacker who has extracted the attested TLS private key positions themselves between a relying party and a genuine attester, forwards the relying party's attestation nonce to that genuine attester, and replays the returned Evidence during its own TLS handshake. Because the PoC never binds the early attestation Evidence to the specific TLS connection, the relying party accepts the relayed Evidence and the attacker impersonates the attested confidential-computing workload and intercepts the session data. Publicly available exploit code and formal ProVerif artifacts demonstrate the relay. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Relay-based impersonation in the CCC-Attestation attested-tls-poc reference implementation (all versions through commit 731ca82) lets an attacker who holds an extracted attested-TLS private key forward a relying party's attestation nonce to a genuine attester and replay the returned, valid Evidence on the attacker's own connection, thereby masquerading as the attested workload and intercepting data meant for it. The root problem is that early attestation Evidence is never cryptographically bound to the TLS connection, so possession of the key plus a position on the relay path is sufficient; CVSS 4.0 scores this 9.1 with AC:H, AT:P and PR:N, meaning no credentials are needed but attack requirements (key control, relay placement) are present. Publicly available exploit code exists in the form of the published ProVerif formal models and relay-attack artifacts, while no CISA KEV entry indicates confirmed active exploitation.
RemediationAI
The primary remediation is not to deploy this code: patch guidance is available upstream via pull request https://github.com/CCC-Attestation/attested-tls-poc/pull/58, which relabels the project as vulnerable, states that formal analysis has shown relay attacks and instructs users not to use the proof-of-concept, so this is an upstream fix (PR/commit) rather than a released patched version and any existing deployment should be treated as unfixed. Teams that have built on the PoC should move to a binding mechanism that correlates Evidence with the Diffie-Hellman shared secret or the handshake/application traffic keys, i.e. one incorporating the early exporter (mechanisms #3, #5 or #7) rather than mechanism #6, and should validate the change against the ProVerif models in the relay-attacks-formal directory before re-deploying; the trade-off is that early-exporter binding requires TLS 1.3 exporter support at both endpoints and changes the Evidence format and verification logic. Rotate and revoke any attested-TLS private keys whose extraction the threat model permits, since key compromise is a hard prerequisite for this attack, and restrict attestation acceptance to sessions where the relying party can confirm freshness of its own nonce end to end. Compensating controls if the PoC must remain in a lab: terminate attestation only over mutually authenticated channels and pin the peer, and treat any attestation result as advisory rather than an authorization decision, accepting that this sacrifices the security guarantee the protocol is meant to provide. Do not rely on network filtering alone, as the relay can be performed from any host on the path between relying party and attester.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
This is a CWE-346 origin validation error in the intra-handshake (early) attestation flow of a TLS 1.3-based proof-of-concept that places a RATS Attester on the TLS server side, as is typical in confidential computing. The repository enumerates seven candidate binding mechanisms for tying Evidence to the handshake, and the PoC implements mechanism #6, a combination of the client's attestation nonce and the server's public key. Because the server public key can be attested without being tied to the Diffie-Hellman shared secret g^xy, the client handshake traffic key k_ch, or the client application traffic key k_c, none of the correlation goals G1, G2 or G3 hold, and the accompanying ProVerif proof of insecurity demonstrates that an attacker who possesses an extracted attested-TLS private key and sits between relying party and attester can splice Evidence from the genuine attester into its own session. References point to the corresponding mbedTLS TLS 1.3 generic handshake code and to the IETF draft-intra-handshake-fail document that generalizes the finding beyond this single implementation. The affected code is a research proof-of-concept rather than a production TLS stack, which limits real-world exposure.
Know when Attested Tls Poc gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
AV:N for network relay and AC:H because the attacker must hold an extracted private key and sit on the relay path; PR:N as the protocol itself requires no auth; C:H/I:H for impersonation and data interception, A:N.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
CCC Attestation SIG attested-tls-poc through commit 731ca82 fails to bind early attestation Evidence to the TLS connection, allowing attackers to relay valid Evidence from a genuine attester. Attackers holding an extracted attested TLS private key can forward the relying party's nonce to a genuine attester and replay its Evidence to impersonate the attested workload and intercept data.
Technical POC Analysis
CWE-346 Origin Validation Error.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Latest POC
3 PoC candidates from github (unverified)
Sign in to open the public PoC links collected for this CVE.
Executive ViewAI
Organizations using the CCC-Attestation attested-tls-poc reference implementation face a critical trust-bypass risk (CVE-2026-112377, CVSS 9.1) in which a party that obtains an attested-TLS private key and controls a relay position can impersonate a trusted workload and intercept traffic intended for it. Publicly available exploit code exists, and the flaw requires no credentials, so any attestation or workload-identity flow built on affected versions through commit 731ca82 should be considered exposed. Leadership should care because compromise of attestation trust can undermine service-to-service authorization and expose sensitive data across dependent systems.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB