What happened
The confidential-computing attestation logic matches firmware/software measurements but fails to bind Evidence to an allowed platform owner or machine identity and does not enforce revocation, enabling cross-platform evidence substitution. A second defect means attestation is only performed once when the attested TLS connection is established, so an attacker who modifies the attester's workload code, state, config, or attached devices after that check can keep the established trust.
Why it matters
Confidential computing is used to guarantee that AI workloads and their weights run on trusted hardware. If attestation can be satisfied by evidence from an attacker-controlled platform, or is only checked once, the integrity and confidentiality guarantees for AI model execution and inference are rendered ineffective.
Attack vector
The verifier accepts TEE attestation Evidence when firmware patch levels and software measurements match, without binding it to an allowed platform owner or unique machine identity and without enforcing revocation. An attacker controlling another platform trusted by the same verifier substitutes valid Evidence from that platform, causing authorization of the wrong platform. Separately, attestation is performed only once when the attested TLS connection is established, so post-check code/state/config changes are not re-attested.
Affected systems
Cocos AI <= 0.8.2 (evidence binding); < 0.9.0 (one-time attestation)
Mitigation
Adopt Cocos AI 0.9.0 and additionally enforce platform-owner/identity binding and revocation in the attestation policy; note the advisory states the flaw cannot be fully fixed in source alone because it originates in the confidential-computing threat model.