---
id: "CVE-2026-112377"
kind: "vulnerability"
aliases: ["CVE-2026-112377"]
title: "attested-tls-poc: attestation evidence not bound to TLS, enabling relay impersonation"
severity: "critical"
cvss: 9.1
epss: null
exploited: false
status: "open"
category: "package"
products: [{"name": "attested-tls-poc", "fixed": [], "affected": "<= 731ca82ed533fc7a1092be980887ae2e34261da2", "ecosystem": "github"}]
ecosystems: []
tags: ["attested-tls", "confidential-computing", "package", "proof-of-concept", "tee-workloads"]
not_affected_if: ["does-not-use-attested-tls-poc", "no-intra-handshake-attestation"]
published_at: "2026-10-19T18:17:05+00:00"
first_seen_at: "2026-10-23T21:57:18+00:00"
updated_at: "2026-10-23T23:24:25+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112377", "first_seen_at": "2026-10-23T21:57:18+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-10-23T23:24:25+00:00"}]
---

# attested-tls-poc: attestation evidence not bound to TLS, enabling relay impersonation

CCC Attestation SIG's attested-tls-poc, a demo of attestation inside the TLS handshake, does not bind early attestation Evidence to the TLS connection. An attacker with an extracted attested-TLS private key can relay the relying party's nonce to a genuine attester, replay its Evidence, impersonate the attested workload and intercept data. The maintainers marked the PoC as vulnerable and have not shipped a fix.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- github:attested-tls-poc affected <= 731ca82ed533fc7a1092be980887ae2e34261da2 fixed ?

## How to check

Check whether you use or copied code from CCC-Attestation/attested-tls-poc (Docker recipes, its mbedtls fork, Veraison/Parsec components): run 'git log' or inspect your vendored commit and compare it to 731ca82ed533fc7a1092be980887ae2e34261da2. Any build at or before that commit is affected. Also check whether your own attested-TLS design signs only a nonce (and/or the server public key) in the Evidence without binding to the handshake.

## Fix

No fixed version or commit as of 2026-10-23; the repo is a proof-of-concept and is declared vulnerable. Do not use it in production. Mitigation: bind Evidence to the TLS session (for example via a TLS exporter value or handshake-transcript secret) as discussed in the intra-handshake.fail work, and protect or rotate attested-TLS private keys that may have been extracted.

## Timeline

- 2026-10-23T21:57:18+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-112377
- 2026-10-23T23:24:25+00:00 analyst — Primary: maintainers' PR #58 (merged 2026-07-17) declares the PoC vulnerable; no fix exists, the CVE is a disclosure of a design flaw in a demo repo. EUVD/GHSA list affected as <= commit 731ca82ed533fc7a1092be980887ae2e34261da2. Not exploited, no KEV, EPSS 0.18%. Related research (intra-handshake.fail, CVE-2026-33697) says other intra-handshake attestation designs share the binding weakness; I did not verify downstream shipping of this code. Severity left at critical per CNA CVSS 4.0 9.1, though real exposure is limited to anyone who copied this PoC.

## Documents

- [advisory] EUVD-2026-104535 / GHSA-hqrh-qq2r-6h96 https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-104535
- [describes] attested-tls-poc PR #58: Add proof of relay attacks (declares PoC vulnerable) https://github.com/CCC-Attestation/attested-tls-poc/pull/58
- [mentions] intra-handshake.fail: formal analysis of attested TLS binding mechanisms https://github.com/muhammad-usama-sardar/intra-handshake.fail

## From the sources

CCC Attestation SIG attested-tls-poc through commit 731ca82 fails to bind early attestation Evidence to the TLS connection, allowing attackers to relay valid Evidence from a genuine attester. Attackers holding an extracted attested TLS private key can forward the relying party's nonce to a genuine attester and replay its Evidence to impersonate the attested workload and intercept data.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_