Cocos Intra-handshake attested TLS implementation is vulnerable to Diversion Attacks
Only affects Cocos 0.8.2 and earlier where platform ownership, unique identity, or revocation is not enforced by the verifier. Fixed in 0.9.0.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 0.9.0
- Who is exposed
- Not reported
Do first: Upgrade to a fixed version: 0.9.0.
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 26/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Cocos AI, a confidential computing system for AI, accepts trusted execution environment attestation evidence without binding it to an allowed platform owner or machine identity, so a remote attacker who controls or compromises another platform trusted by the same verifier can substitute that platform's valid evidence and get the wrong platform authorized. The flaw is reachable over the network without logging in, and it is fixed in a later release, though it cannot be fully resolved by a source code patch alone because it stems from the confidential computing threat model itself.
Read the original description
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.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure17/25No login or user action needed, reachable over the network without a login · Unknown: Advisories don't say whether default setups are affected
- Reach?/20Unknown. No tracked technology or package matched
- Severity9.1/10CVSS 9.1
- No patch0/5No signal
What would change the score
- Would score about 71 if added to CISA KEV
- Would score about 66 if CISA's SSVC rates exploitation active
- Would score about 31 if advisories confirm default setups are exposed
What to do
Upgrade to a fixed version: 0.9.0.
Workaround: Define an explicit list of allowed unique hardware instance identifiers of the supported TEEs and check the PIID field from the PCK certificate against it during appraisal.
Timeline
- CVE published
- First seen by cve.now
- Posted on X by cve.now
Affected versions
- ultravioletrs cocos
through 0.8.2
Evidence 5
- Advisory
- Repository
- Link
- Link
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-119344
Is CVE-2026-119344 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
An attacker who controls or compromises another confidential-computing platform can present valid attestation evidence from that platform. The verifier may then authorize the wrong platform, because the evidence is trusted by the same verifier.Source: github.com
Which versions are affected by CVE-2026-119344?
cocos: through 0.8.2.Source: cve.now feed data
Am I affected, and how do I check?
Cocos versions up to and including 0.8.2 are in scope. The exposure applies only where platform ownership, unique identity, or revocation is not enforced, so check the installed Cocos version and whether the verifier enforces those checks.Source: github.com
How do I fix CVE-2026-119344?
Upgrade to Cocos 0.9.0 or later, which contains the fix. If an upgrade is not possible, define an explicit list of allowed unique hardware instance identifiers for the supported TEEs and check the PIID field from the PCK certificate against it during appraisal.Source: github.com