CVE-2026-112377 in attested-tls-poc
Summary
by MITRE • 10/19/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability described in CCC Attestation SIG attested-tls-poc represents a critical failure in the cryptographic binding mechanism within Transport Layer Security (TLS) implementations that utilize remote attestation for endpoint verification. This flaw specifically affects systems relying on early evidence generation, where an attester produces proof of its integrity and identity before the full TLS handshake is completed. The core technical deficiency lies in the absence of proper key commitment or nonce binding between the generated attestation evidence and the specific TLS session parameters. In a secure implementation, the private keys used to sign the attestation must be cryptographically bound to the ephemeral exchange values exchanged during the handshake, such as nonces from both the client and server. Without this binding, the signature on the attestation does not uniquely identify the current connection context, creating a malleability issue that attackers can exploit through relay attacks.
From an operational perspective, this flaw allows for sophisticated man-in-the-middle scenarios where an attacker with access to an extracted or compromised private key associated with an attested workload can intercept and manipulate communications. The attack vector involves the adversary capturing the nonce sent by the relying party during the TLS handshake and forwarding it to a genuine, uncompromised attester. Because the protocol fails to bind this specific nonce to the subsequent evidence generation process in a way that prevents reuse across different sessions or contexts, the genuine attester produces valid cryptographic evidence based on that captured nonce. The attacker then relays this freshly generated but contextually misaligned evidence back to the relying party. Since the signature is mathematically valid and originates from a trusted source, the relying party accepts it as proof of identity for the compromised workload, effectively allowing the attacker to impersonate the legitimate service.
This vulnerability aligns with CWE-295 Improper Certificate Validation and CWE-347 Improper Verification of Cryptographic Signature, as the system fails to ensure that the cryptographic evidence is uniquely tied to the specific authentication context. Furthermore, it maps directly to MITRE ATT&CK technique T1086 - Indirect Command Execution via Relay Attacks, specifically within the context of credential access and lateral movement in zero-trust architectures. The ability to relay valid credentials or proofs from a secure environment to an untrusted one undermines the fundamental premise of remote attestation, which is to guarantee that code running on a device has not been tampered with and originates from a trusted source. By bypassing this assurance through session hijacking techniques, attackers can gain unauthorized access to sensitive data streams protected by TLS encryption.
Mitigation strategies must focus on enforcing strict cryptographic binding between the attestation evidence and the TLS handshake parameters. Implementers should ensure that the private key used for signing the attestation is derived from or bound to the ephemeral shared secret established during the Diffie-Hellman exchange, a concept known as key commitment. This ensures that any change in session parameters results in an invalid signature if replayed in a different context. Additionally, protocols should incorporate unique nonces into the data being signed by the attester, ensuring that each piece of evidence is valid only for its specific transaction or connection instance. Regular auditing of TLS configurations and adherence to updated standards such as those defined by IETF regarding post-quantum cryptography and secure key exchange mechanisms can further reduce the risk surface associated with these types of relay attacks.