CVE-2026-33697

High

Published: 27 March 2026

Published

27 March 2026

Modified

10 April 2026

KEV Added

—

Patch

—

CVSS Score 7.5 CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N

EPSS Score 0.0000 0.2th percentile

Risk Priority 15 60% EPSS · 20% KEV · 20% CVSS

Summary

CVE-2026-33697 is a high-severity Key Exchange without Entity Authentication (CWE-322) vulnerability in Ultraviolet Cocos Ai. Its CVSS base score is 7.5 (High).

Operationally, exploitation aligns with the MITRE ATT&CK technique Adversary-in-the-Middle (T1557); ranked at the 0.2th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

This vulnerability is AI-related — categorised as Other AI Platforms.

The strongest mitigations our analysis identified are NIST 800-53 SC-12 (Cryptographic Key Establishment and Management) and SC-23 (Session Authenticity).

Threat & Defense at a Glance

What attackers do: exploitation maps to Adversary-in-the-Middle (T1557). What defenders deploy: see the NIST 800-53 controls recommended below.

Threat & Defense Details

Mitigating Controls (NIST 800-53 r5)AI

SC-23 Session Authenticity good match

prevent

Directly counters the relay attack by ensuring mechanisms verify the authenticity of aTLS sessions, preventing impersonation where attestation evidence is not bound to the TLS channel.

SC-12 Cryptographic Key Establishment and Management good match

prevent

Mandates secure establishment and management of cryptographic keys, including ephemeral TLS private keys, to resist extraction via physical access, transient execution, or side-channel attacks.

SC-17 Public Key Infrastructure Certificates partial match

prevent

Supports mutual aTLS with CA-signed certificates as a workaround, providing additional entity authentication beyond vulnerable attestation binding.

MITRE ATT&CK Enterprise TechniquesAI

T1557 Adversary-in-the-Middle Credential Access

Adversaries may attempt to position themselves between two or more networked devices using an adversary-in-the-middle (AiTM) technique to support follow-on behaviors such as [Network Sniffing](https://attack.

attack.mitre.org →

Why these techniques?

Vulnerability's flawed ephemeral key binding directly enables relay attacks that impersonate the attested service and intercept/divert sessions, mapping to Adversary-in-the-Middle (T1557).

Confidence: MEDIUM · MITRE ATT&CK Enterprise v18.1

NVD Description

Cocos AI is a confidential computing system for AI. The current implementation of attested TLS (aTLS) in CoCoS is vulnerable to a relay attack affecting all versions from v0.4.0 through v0.8.2. This vulnerability is present in both the AMD SEV-SNP…

and Intel TDX deployment targets supported by CoCoS. In the affected design, an attacker may be able to extract the ephemeral TLS private key used during the intra-handshake attestation. Because the attestation evidence is bound to the ephemeral key but not to the TLS channel, possession of that key is sufficient to relay or divert the attested TLS session. A client will accept the connection under false assumptions about the endpoint it is communicating with — the attestation report cannot distinguish the genuine attested service from the attacker's relay. This undermines the intended authentication guarantees of attested TLS. A successful attack may allow an attacker to impersonate an attested CoCoS service and access data or operations that the client intended to send only to the genuine attested endpoint. Exploitation requires the attacker to first extract the ephemeral TLS private key, which is possible through physical access to the server hardware, transient execution attacks, or side-channel attacks. Note that the aTLS implementation was fully redesigned in v0.7.0, but the redesign does not address this vulnerability. The relay attack weakness is architectural and affects all releases in the v0.4.0–v0.8.2 range. This vulnerability class was formally analyzed and demonstrated across multiple attested TLS implementations, including CoCoS, by researchers whose findings were disclosed to the IETF TLS Working Group. Formal verification was conducted using ProVerif. As of time of publication, there is no patch available. No complete workaround is available. The following hardening measures reduce but do not eliminate the risk: Keep TEE firmware and microcode up to date to reduce the key-extraction surface; define strict attestation policies that validate all available report fields, including firmware versions, TCB levels, and platform configuration registers; and/or enable mutual aTLS with CA-signed certificates where deployment architecture permits.

Deeper analysisAI

CVE-2026-33697 affects the attested TLS (aTLS) implementation in CoCoS, a confidential computing system for AI, across all versions from v0.4.0 through v0.8.2. The vulnerability impacts both AMD SEV-SNP and Intel TDX deployment targets. In the flawed design, an attacker can extract the ephemeral TLS private key used during the intra-handshake attestation. Since the attestation evidence binds to this ephemeral key but not to the TLS channel itself, possession of the key enables relaying or diverting the attested TLS session, undermining the authentication guarantees of aTLS.

Exploitation requires an attacker with local access (AV:L, PR:L) to first extract the ephemeral key via physical access to the server hardware, transient execution attacks, or side-channel attacks, under high attack complexity (AC:H). A successful relay attack allows the attacker to impersonate the genuine attested CoCoS service, leading to high confidentiality and integrity impacts (C:H/I:H) with scoped impact (S:C). Clients accept relayed connections under false assumptions about the endpoint, as the attestation report cannot distinguish the legitimate service from the attacker's relay, potentially exposing data or operations intended exclusively for the authentic endpoint.

The GitHub security advisory (GHSA-vfgg-mvxx-mgg7) confirms no patch is available as of publication, and the architectural weakness persisted despite a full aTLS redesign in v0.7.0. No complete workaround exists, but hardening measures can reduce risk: maintain up-to-date TEE firmware and microcode to shrink the key-extraction surface; enforce strict attestation policies validating all report fields like firmware versions, TCB levels, and platform configuration registers; and deploy mutual aTLS with CA-signed certificates where feasible.

This vulnerability class was formally analyzed and demonstrated across multiple aTLS implementations, including CoCoS, using ProVerif, with findings disclosed to the IETF TLS Working Group. It carries a CVSS v3.1 base score of 7.5 and maps to CWE-322 (Key Exchange without Entity Authentication) and CWE-346 (Origin Validation Error). As a flaw in AI confidential computing, it highlights risks to trusted execution environments for machine learning workloads.