CVE-2026-33697
Ultraviolet Cocos Ai 0.4.0 – 0.9.0
Raw vector
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:NSummary
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.4th 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 Platforms; in the Protocol-Specific Risks risk domain.
The strongest mitigations our analysis identified map to AC-4 (Information Flow Enforcement) and IA-2 (Identification and Authentication (Organizational Users)) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
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.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-16488
Vulnerability Data
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…
more
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.
- CWE(s)
AI Security AnalysisAI
- AI Category
- Other Platforms
- Risk Domain
- Protocol-Specific Risks
- OWASP Top 10 for LLMs 2025
- None mapped
- Classification Reason
- Matched keywords: ai
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 3 hardening rules · 1 OS baseline
V12.1.3
Mitigating Controls (NIST 800-53 r5) AI
Requiring device identification and authentication before establishing connections prevents unauthenticated key exchanges with unknown devices.
Information flow enforcement directly requires validating the source of data before allowing transmission or receipt.
Requiring unique identification and authentication of users before any privileged action stops key exchange from occurring with unauthenticated parties.
Requiring identification and authentication of non-organizational users blocks key exchange with unauthenticated external actors.
Requiring proper cryptographic key establishment and management directly stops unauthenticated key-exchange implementations.
Issuing or obtaining PKI certificates under an approved policy supplies the entity authentication missing from unauthenticated key exchange.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Requiring authentication of services/hardware prevents unauthenticated key exchange.
Verifying identity assertions enforces origin validation for conveyed claims.
Documenting authorized flows supports origin validation by defining expected sources.
Identity proofing and binding directly supports verifying actors before key exchange.
Protecting data-in-transit implies use of authenticated key exchange but does not explicitly require entity authentication.
Protecting networks from unauthorized access requires origin checks on communication sources.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Use of cryptography mandates authenticated key-exchange mechanisms, directly addressing the lack of entity authentication.
Security testing can detect missing entity authentication during key exchange.
Secure authentication directly prevents unauthenticated key exchange by requiring verified identities before keys are established.
Identity management provides the verified identities required before key exchange occurs.
Network security policies can require authenticated channels, indirectly reducing the risk of unauthenticated key exchange.
Security of network services includes requirements for authenticated key exchange in service protocols.
Hardening callouts derived
Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (authoritative rows only; rows rated `none` are excluded).
Oracle Linux 8 (3 rules)
- V-248574 YUM must be configured to prevent the installation of patches, service packs, device drivers, or OL 8 system components that have not been digitally signed using a certificate that is recognized and approved by the organization. prevents CWE-346
- V-248575 OL 8 must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. prevents CWE-346
- V-248827 OL 8 must not have the rsh-server package installed. prevents CWE-346