Attested TLS Is Broken: AI Inference on Confidential Compute Exposed

The security promise of confidential computing is straightforward: your sensitive data gets processed inside a Trusted Execution Environment, and cryptographic attestation proves you’re actually talking to that genuine, unmodified enclave. That promise is now in serious question.

Research published July 4, 2026 by Muhammad Usama Sardar at TU Dresden shows that attested TLS, the protocol that makes this promise hold, is fundamentally broken. Not “has edge cases.” Broken in a way that no current implementation fully prevents. CVE-2026-33697 has been assigned (CVSS 7.5), and the list of affected systems includes AI inference platforms by name.

What Attested TLS Is Supposed to Do

Confidential computing is built around the idea of a Trusted Execution Environment: an isolated hardware-protected enclave where code runs without the host operating system, hypervisor, or cloud provider being able to inspect or tamper with it. For AI, this is increasingly important. Model providers want to run inference on sensitive client data. Healthcare companies want to process patient records with AI. Meta built WhatsApp Private Processing, which promises that AI runs on your private messages in a TEE that even Meta cannot access.

Attested TLS is the cryptographic mechanism that makes those promises verifiable. A client connects, the server presents attestation evidence proving it’s a genuine TEE, and that evidence is bound to the TLS connection. The client can verify it’s really talking to the enclave, not an impersonator.

Sardar ran this mechanism through formal verification using ProVerif, a tool for proving or disproving security properties of cryptographic protocols. The result: it doesn’t actually deliver what it promises.

Relay Attacks and Diversion Attacks

The two attack classes the research identifies:

A relay attack routes a client’s connection through a compromised machine sitting in the middle. The compromised machine forwards traffic to a genuine TEE, gets valid attestation evidence back, and presents it to the client. The client sees valid attestation but is talking to the attacker’s relay, not the TEE directly. Data can be copied or modified in transit.

A diversion attack is subtler. The attacker redirects the connection to a completely different machine running identical software, anywhere in the world. The attestation evidence is technically valid because the software is unmodified. But the computation happens on infrastructure the client has no relationship with, and they have no way to know.

Sardar tested seven different ways of cryptographically binding attestation evidence to a TLS connection. None of them fully prevent relay attacks in current implementations. He identified three binding levels, with Level 3, binding the attestation to the TLS application traffic key, being theoretically the strongest. Getting to Level 3, though, “may not be possible” within current attested TLS architecture.

Who Is Affected

The concrete disclosures:

Cocos AI (versions 0.4.0 through 0.8.2) is directly named in the CVE. Cocos AI is a confidential computing platform used for AI and data processing workloads. Version 0.8.3 addresses the vulnerability.

Meta’s WhatsApp Private Processing uses TEEs as the core of its privacy guarantee for AI features. The research confirms this deployment is affected. Meta has not issued a patch timeline as of publication.

Edgeless Systems’ Contrast platform is also named. Edgeless builds confidential containers for Kubernetes environments, including AI inference workloads.

Germany’s Federal Office for Information Security (BSI) has separately concluded that confidential computing “cannot satisfy the requirements for digital sovereignty” on its own, which this research empirically supports.

The Responsible Disclosure Problem

There’s a separate story here about the disclosure process. Sardar’s work went through a working group that included major vendors with direct financial interest in confidential computing’s security reputation. That group delayed the release of his proof-of-concept for over a week. The PoC was eventually published independently, but the delay illustrates a structural problem: vulnerability disclosure in a market where the affected vendors also control the standards process.

The research went public regardless.

What AI Infrastructure Teams Should Do

The practical guidance, in rough priority order:

Update Cocos AI to 0.8.3 or later immediately. This is the one patched version named in the disclosure.

For other confidential computing platforms, check vendor advisories. Edgeless Systems and Meta have been notified; watch for patch announcements.

Reassess your threat model if confidential computing is the sole control protecting sensitive AI inference. The research doesn’t mean TEEs are useless — they still provide meaningful isolation from host-level attackers. But relay and diversion attacks from network-positioned adversaries are now a documented, formally verified risk, not a theoretical concern.

Apply defense-in-depth. Attestation trust alone is not sufficient for high-sensitivity AI workloads. Application-layer authentication, end-to-end encryption of inputs before they reach the TEE, and logging of attestation verification attempts add layers that reduce the practical impact of these attacks.

The broader implication for AI security is significant. Confidential computing has become a common architectural response to the question “how do you run AI on sensitive data?” That answer just got more complicated.

References

• The Register — Confidential Computing’s Core Trust Mechanism is Broken. The Fix May Not Exist