CVE-2026-33697: Cocos AI Auth Bypass Vulnerability

CVE-2026-33697 Overview

CVE-2026-33697 is a relay attack vulnerability affecting the attested TLS (aTLS) implementation in Cocos AI, a confidential computing system for AI workloads. The vulnerability affects all versions from v0.4.0 through v0.8.2 and is present in both AMD SEV-SNP and Intel TDX deployment targets supported by CoCoS.

The fundamental weakness lies in the design of the aTLS implementation: while attestation evidence is bound to the ephemeral TLS key, it is not bound to the TLS channel itself. This architectural flaw allows an attacker who can extract the ephemeral TLS private key to relay or divert the attested TLS session, impersonating the legitimate attested service.

Critical Impact

An attacker can impersonate an attested CoCoS service and access data or operations that clients intended to send only to the genuine attested endpoint, completely undermining the authentication guarantees of attested TLS.

Affected Products

• Cocos AI v0.4.0 through v0.8.2
• AMD SEV-SNP deployment targets
• Intel TDX deployment targets

Discovery Timeline

• 2026-03-27 - CVE CVE-2026-33697 published to NVD
• 2026-03-30 - Last updated in NVD database

Technical Details for CVE-2026-33697

Vulnerability Analysis

This vulnerability represents an architectural weakness classified as CWE-322 (Key Exchange without Entity Authentication). The attested TLS implementation in CoCoS fails to properly bind attestation evidence to the TLS channel, creating a fundamental authentication gap.

In confidential computing environments, attested TLS is designed to provide cryptographic proof that a client is communicating with a genuine Trusted Execution Environment (TEE). However, the current implementation only binds the attestation report to the ephemeral TLS private key, not to the complete TLS session. This means that an attacker who can extract the ephemeral key can relay the entire attested session while the client continues to believe it is communicating with the authentic attested service.

The vulnerability was formally analyzed and demonstrated across multiple attested TLS implementations by researchers who disclosed their findings to the IETF TLS Working Group. Formal verification was conducted using ProVerif, confirming the architectural nature of this weakness.

Root Cause

The root cause is an architectural design flaw in how attestation evidence is bound during the TLS handshake. The attestation report proves the identity and integrity of the TEE but fails to cryptographically bind this proof to the specific TLS channel being established. While the ephemeral key is included in the attestation evidence, this binding is insufficient because the attestation report cannot distinguish whether the TLS session terminates at the genuine attested service or at an attacker's relay point.

Note that the aTLS implementation was fully redesigned in v0.7.0, but this redesign does not address the fundamental vulnerability. The relay attack weakness is architectural and persists across the entire v0.4.0 through v0.8.2 version range.

Attack Vector

Exploitation of this vulnerability requires the attacker to first extract the ephemeral TLS private key from the TEE. This can be achieved through several attack surfaces:

Physical Access: Direct physical access to the server hardware may allow extraction of cryptographic material through hardware-based attacks.

Transient Execution Attacks: Side-channel vulnerabilities such as Spectre-class attacks against the TEE could potentially leak the ephemeral key material.

Side-Channel Attacks: Various side-channel techniques targeting the cryptographic operations within the TEE may expose the ephemeral private key.

Once the ephemeral TLS private key is obtained, the attacker can establish a relay position between the client and the genuine service. The client's attestation verification will succeed because the attestation report is valid and bound to the correct key—but the TLS channel terminates at the attacker's relay rather than the genuine endpoint.

Detection Methods for CVE-2026-33697

Indicators of Compromise

• Unexpected network routing or traffic interception between clients and CoCoS services
• Anomalous TLS session establishment patterns or connection latency inconsistent with direct communication
• Evidence of physical tampering with server hardware hosting TEE workloads
• Signs of transient execution or side-channel exploitation attempts in TEE logs

Detection Strategies

• Implement network-level monitoring to detect man-in-the-middle positioning between clients and attested services
• Deploy intrusion detection systems to identify suspicious network topology changes
• Monitor for indicators of side-channel or transient execution attacks targeting TEE environments
• Audit TEE attestation logs for unusual patterns in session establishment

Monitoring Recommendations

• Enable comprehensive logging of all aTLS handshake operations and attestation verifications
• Implement out-of-band verification mechanisms to cross-check attested endpoint identity
• Monitor TEE firmware and microcode integrity to detect compromise of the key-extraction surface
• Review attestation policy compliance and track any deviations from expected report field values

How to Mitigate CVE-2026-33697

Immediate Actions Required

• Evaluate the risk exposure of CoCoS deployments in the v0.4.0 through v0.8.2 range based on your threat model
• Keep TEE firmware and microcode up to date to reduce the key-extraction attack surface
• Define strict attestation policies that validate all available report fields, including firmware versions, TCB levels, and platform configuration registers
• Enable mutual aTLS with CA-signed certificates where deployment architecture permits

Patch Information

As of the time of publication, there is no patch available for this vulnerability. The weakness is architectural in nature and affects all releases in the v0.4.0 through v0.8.2 range. Users should monitor the GitHub Security Advisory for updates on potential fixes.

Workarounds

• Keep TEE firmware and microcode current to minimize the attack surface for ephemeral key extraction
• Implement strict attestation policies validating firmware versions, TCB levels, and all platform configuration registers
• Enable mutual aTLS with CA-signed certificates where your deployment architecture supports this configuration
• Consider implementing additional out-of-band verification mechanisms for high-security workloads
• Restrict physical access to server hardware hosting TEE workloads

Note that no complete workaround is available. The hardening measures listed above reduce but do not eliminate the risk.