CVE-2026-92701 in Cocos
Summary
by MITRE • 09/18/2026
trusted execution environments. In versions up to and including 0.8.2, the intra-handshake attested TLS (aTLS) Intel TDX verification path does not copy the expected current-session freshness value into the TDX quote-body policy before quote validation, so structurally valid TDX QuoteV4 Evidence is accepted without checking that its REPORT_DATA field matches the reportData expected for the current session. A relying party using this path can therefore accept Evidence with a mismatched or reused reportData and release application data after the handshake, enabling session-misbinding to an unintended attestation context. The issue is fixed in version 0.9.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability described pertains to Intel Trust Domain Extensions (TDX) within trusted execution environments, specifically affecting versions up to and including 0.8.2 of the intra-handshake attested TLS implementation. This flaw represents a critical failure in the cryptographic binding mechanism that is essential for establishing secure communication channels between parties relying on hardware-based attestations. The core technical deficiency lies in the verification path where the system fails to copy the expected current-session freshness value, often referred to as reportData or nonce, into the TDX quote-body policy prior to validating the TDX QuoteV4 Evidence. In a correctly implemented attestation protocol, this step is mandatory to ensure that the cryptographic evidence presented by the remote party corresponds directly to the specific session being established. By omitting this copy operation, the verification logic becomes structurally blind to discrepancies between the freshness value expected for the current handshake and the actual data contained within the reported measurements of the TDX quote.
As a direct consequence of this implementation error, any structurally valid TDX QuoteV4 Evidence is accepted by the relying party even if its REPORT_DATA field does not match the reportData expected for the ongoing session. This lack of strict binding allows an attacker to perform a session-misbinding attack. In such an scenario, an adversary can intercept or manipulate the handshake process and present evidence from a previous valid session or from a different attestation context entirely. Because the system fails to verify that the REPORT_DATA matches the current session's requirements, it erroneously concludes that the remote party is legitimate and operating within the expected trusted execution environment. This effectively bypasses the security guarantees provided by Intel TDX, reducing hardware-based attestation to a mere format check rather than a robust proof of identity and state integrity for the specific connection attempt.
The operational impact of this vulnerability is severe, as it enables session-misbinding which can lead to unauthorized access or data exfiltration under false pretenses. Once the handshake completes successfully due to the flawed verification logic, the relying party proceeds to release application data over what appears to be a secure channel but is actually associated with an unintended attestation context. An attacker could potentially replay old valid quotes from compromised or different environments to gain access to sensitive resources protected by this TLS implementation. This undermines the fundamental purpose of using trusted execution environments for high-security communications, as it allows malicious actors to masquerade as legitimate peers without possessing the correct current-session cryptographic material. The ability to reuse stale evidence also facilitates replay attacks where historical valid attestations are injected into new connections to deceive the verification process.
This vulnerability aligns with CWE-295 Improper Certificate Validation and CWE-347 Improper Verification of Cryptographic Signature, as it involves a failure to properly validate cryptographic evidence against expected session parameters. From an offensive security perspective, this flaw is exploitable via MITM (Man-in-the-Middle) attacks that fall under the ATT&CK technique T1557 Adversary-in-the-Middle, specifically leveraging the ability to substitute or replay authentication artifacts. To mitigate this risk, organizations must ensure they are running version 0.9.0 or later of the affected software, where the code path has been corrected to properly copy and verify the session freshness value within the TDX quote-body policy. Additionally, security architects should review their TLS configurations to enforce strict nonce validation in all attestation-based handshake flows, ensuring that every piece of cryptographic evidence is uniquely bound to its corresponding session context through rigorous comparison of expected versus actual report data fields.