CVE-2026-33697 identifies a critical architectural vulnerability in the attested TLS (aTLS) implementation within the CoCoS confidential computing system for AI workloads. CoCoS supports deployment on AMD SEV-SNP and Intel TDX trusted execution environments (TEEs). The vulnerability arises because the ephemeral TLS private key used during the intra-handshake attestation can be extracted by attackers through physical access, transient execution attacks, or side-channel attacks. The attestation evidence is cryptographically bound to this ephemeral key but not to the TLS channel itself, meaning possession of the ephemeral key allows an attacker to relay or divert the attested TLS session. Consequently, clients cannot distinguish between genuine attested services and attacker-relayed connections, breaking the entity authentication guarantees of aTLS. This flaw enables attackers to impersonate attested CoCoS services and access data or operations intended only for the genuine endpoint. The vulnerability affects all CoCoS versions from 0.4.0 to 0.8.2, including the redesigned aTLS implementation introduced in v0.7.0, as the weakness is architectural rather than implementation-specific. The issue was formally analyzed and demonstrated across multiple attested TLS implementations, with formal verification using ProVerif. No patch or complete workaround is currently available. Mitigation strategies include keeping TEE firmware and microcode updated to reduce key-extraction attack surfaces, enforcing strict attestation policies validating all report fields (firmware versions, TCB levels, platform configuration registers), and enabling mutual aTLS with CA-signed certificates where feasible. The CVSS v3.1 score is 7.5 (high), reflecting local attack vector, high complexity, low privileges required, no user interaction, and high confidentiality and integrity impact with no availability impact.

The vulnerability poses a significant risk to organizations deploying CoCoS for confidential AI computing, particularly those relying on attested TLS to ensure endpoint authenticity and secure intra-handshake attestation. Successful exploitation allows attackers to impersonate attested services, potentially gaining unauthorized access to sensitive AI model data, inference results, or control operations intended only for trusted endpoints. This undermines the confidentiality and integrity of AI workloads running within TEEs on AMD SEV-SNP and Intel TDX platforms. The attack requires advanced capabilities such as physical access or sophisticated side-channel or transient execution attacks, limiting broad exploitation but posing a severe threat in high-value environments. The inability to distinguish genuine from relayed attested TLS sessions compromises trust in the attestation mechanism, potentially leading to data breaches, intellectual property theft, or manipulation of AI computations. The lack of a patch or complete workaround increases exposure duration. Organizations with critical AI workloads in confidential computing environments face operational and reputational risks if exploited.

Given the absence of a patch, organizations must adopt layered mitigations to reduce risk. First, ensure all TEE firmware and microcode are up to date to minimize vulnerabilities enabling ephemeral key extraction. Second, implement strict attestation policies that validate all attestation report fields, including firmware versions, Trusted Computing Base (TCB) levels, and platform configuration registers, to detect anomalies or unauthorized changes. Third, where deployment architecture permits, enable mutual attested TLS with CA-signed certificates to strengthen endpoint authentication beyond ephemeral key binding. Fourth, restrict physical access to servers hosting CoCoS to prevent direct key extraction attacks. Fifth, monitor for signs of side-channel or transient execution attacks and apply relevant hardware and software mitigations. Finally, maintain close coordination with the CoCoS vendor and ultravioletrs project for updates or patches and plan for rapid deployment once available. Consider isolating or limiting sensitive AI workloads until the vulnerability is remediated.