Ultraviolet CoCoS CVE-2026-92701

Exploitation requires the relying party to be using the intra-handshake attested TLS (aTLS) verification path against an Intel TDX deployment target on cocos version 0.8.2 or earlier; AMD SEV-SNP and other attestation paths are not implicated by this specific reportData-check defect. The attacker must be able to supply the TDX QuoteV4 Evidence during the handshake - i.e., act as the attesting counterparty or relay a previously captured/foreign quote - since the flaw is that the verifier accepts any structurally valid quote without matching REPORT_DATA to the expected session reportData. Limiting factors: it only affects the TDX branch of aTLS, requires a structurally valid TDX quote to be presented, and is fixed by upgrading to v0.9.0; recommended hardening (strict attestation policies validating all report fields, mutual aTLS with CA-signed certs) further constrains it.

This is a genuine high-priority attestation-integrity flaw, not a CVSS-inflated non-issue, but the vendor's 9.1 slightly overstates ease of exploitation. The CVSS vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H) correctly captures that this is a network-reachable, unauthenticated defeat of a security control - the core value proposition of confidential computing (proving you are talking to the genuine TEE). The bug is a fail-open verification defect: the Intel TDX aTLS path never copies the expected per-session reportData into the quote-body policy, so REPORT_DATA freshness/binding is simply never checked, meaning ANY structurally valid TDX QuoteV4 (including a reused or relayed one) is accepted. However, realistic exploitation requires the attacker to possess a valid TDX quote and to be positioned as the attestation counterparty/relay in the handshake, which argues for AC:H rather than AC:L. No EPSS score, KEV listing, or public POC is present in the provided data, so there is no evidence of active exploitation - the risk is architectural/theoretical at time of analysis. Note a key data conflict: the linked v0.9.0 release notes describe a DIFFERENT CVE (CVE-2026-33697, relay via extracted ephemeral TLS keys, CVSS 7.5, GHSA-vfgg-mvxx-mgg7), whereas this CVE (CVE-2026-92701) is the reportData-check omission under GHSA-4px3-wj2x-xx47; both are fixed in the same v0.9.0 release but should not be conflated.

An attacker positioned as (or relaying to) the attestation counterparty presents a client/relying party using the intra-handshake Intel TDX aTLS path with a structurally valid but stale or foreign TDX QuoteV4 whose REPORT_DATA does not match the current session. Because the verifier never loads the expected session reportData into the quote policy, the mismatched evidence is accepted and the relying party releases application data to an unintended attestation context. No public exploit code is identified in the provided data, and there is no confirmation of active exploitation.