Cocos AI EUVD-2026-83192

Exploitation requires the relying party to invoke the intra-handshake aTLS AMD SEV-SNP verification path WITHOUT an expected reportData value (nil, empty, or omitted), causing the SEV-SNP policy ReportData to remain unset so no connection-binding/freshness check is enforced. The attacker must also possess a valid but unrelated or stale SEV-SNP Evidence to present. It is LIMITED by: callers that supply a non-empty reportData are unaffected (that path is still validated); only Cocos AI versions ≤0.8.2 on the SEV-SNP aTLS trust-decision path; and the need to acquire a usable foreign/stale attestation blob. Only applies where aTLS results feed a trust or authorization decision.

The vendor CVSS of 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) reflects a serious break in the core trust guarantee of a confidential-computing system: an attestation-freshness/origin-validation failure (CWE-346) that lets a verifier accept SEV-SNP Evidence not bound to the current connection. However, the raw score somewhat overstates real-world exposure because exploitation is GATED on the relying party using the aTLS path WITHOUT an expected reportData (nil/empty/omitted) - a non-empty reportData is still validated correctly, so hardened callers are unaffected. This is a genuine trust-boundary bypass, not a low-real-risk high-CVSS artifact, but it is conditional on deployment/API usage rather than a universal remote pop. There is no EPSS score, no CISA KEV listing, and no proof-of-concept in the provided data (advisory, PR #582, commit 80bf813c, and the v0.9.0 release tag only). Exploitation status: no public exploit identified at time of analysis. The AV:N/PR:N/AC:L metrics are plausible for the network path, but I assess AC:H is more honest because the attacker must obtain a valid-but-unrelated/stale SEV-SNP Evidence blob AND the victim relying party must be on the no-reportData code path - verify the default configuration with the vendor.

An attacker who can obtain any valid but unrelated or stale AMD SEV-SNP attestation Evidence connects to a relying party that performs an aTLS trust/authorization decision without supplying an expected reportData. Because the SEV-SNP policy ReportData is left unset, the verifier does not bind the attestation to the current connection and accepts the replayed/foreign Evidence, inducing the relying party to trust an unintended attestation context (e.g., a non-genuine or attacker-influenced TEE). No public proof-of-concept is included in the referenced advisory or PR.