CVE-2026-119344
CriticalCVSS 9.1Summary
Cocos AI in version 0.8.2 and earlier accepts trusted execution environment attestation Evidence when firmware patch levels and software measurements match, without binding the Evidence to an allowed platform owner or unique machine identity and without enforcing revocation. A remote attacker who controls or compromises another platform trusted by the same verifier can substitute valid Evidence from that platform and cause authorization of the wrong platform. The vulnerability is addressed in 0.9.0, but cannot be patched in source code alone since it arises from the confidential computing threat model itself.
Risk Assessment
The organization may accept attestation from a compromised or foreign platform, undermining trust in confidential computing and potentially exposing or processing data in the wrong environment. The risk is especially relevant for multi-platform deployments sharing a common verifier.
Recommendation
Upgrade Cocos AI to version 0.9.0 and implement additional binding of attestation Evidence to a specific platform owner and revocation lists. Review the threat model and configure the verifier to reject Evidence from unauthorized platforms.
Other vulnerabilities in Cocos AI
See all- CVE-2026-119345High
Cocos AI is a confidential computing system for AI. Prior to version 0.9.0, attestation is performed only once when an attested TLS connection is established. An attacker who can modify the attester's workload code, memory-backed state, configuration, or attached devices after that check can keep the existing connection open while the peer continues trusting stale initial evidence. This gap is especially significant for long-lived connections because the verifier has no mechanism to detect the changed state.
- CVE-2026-92702Critical
Cocos AI is a confidential computing system for AI. In Cocos AI 0.8.2 and earlier, VerifyAttestationReportTLS in the AMD SEV-SNP verifier sets Policy.ReportData only when its caller supplies non-empty expected reportData. A relying-party integration that passes nil or empty expected reportData while relying on that value for current-session freshness can therefore accept SEV-SNP evidence unrelated to the current connection and make a trust, authorization, or application-data release decision for an unintended attestation context. This issue was fixed in Cocos AI 0.9.0 by removing the affected verifier path as part of the migration to post-handshake attestation.
- CVE-2026-92701Critical
Cocos AI is a confidential computing system for AI. In Cocos AI 0.8.2 and earlier, VerifTeeAttestation in the Intel TDX aTLS verifier receives an expected current-session value but does not apply it to TdQuoteBodyPolicy.ReportData before validating TDX QuoteV4 evidence. The verifier can consequently accept structurally valid evidence containing mismatched or reused REPORT_DATA for the current TLS session, causing the relying party to release application data or make a trust or authorization decision for an unrelated attestation context. This issue was fixed in Cocos AI 0.9.0 by removing the affected verifier path as part of the migration to post-handshake attestation.
Original NVD description (English source)
Cocos AI is a confidential computing system for AI. In version 0.8.2 and earlier, Cocos AI accepts trusted execution environment attestation Evidence when firmware patch levels and software measurements match, without binding the Evidence to an allowed platform owner or unique machine identity and without enforcing revocation. A remote attacker who controls or compromises another platform trusted by the same verifier can substitute valid Evidence from that platform and cause authorization of the wrong platform. This vulnerability is addressed in 0.9.0. However, this vulnerability can't be patched in source code alone, since the vulnerability arises from the confidential computing threat model itself.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS