CVE-2026-108267 in Privasys
Summary
by MITRE • 10/09/2026
Privasys Go is a maintained fork of the Go programming language that adds RA-TLS support to crypto/tls. Prior to privasys-v0.5.1-go1.26.5, challenge-mode RA-TLS certificates bound quote ReportData to the certificate public key and client nonce but not to the active TLS session. An attacker who obtained an enclave TLS private key could relay a genuine quote onto another connection, causing a relying party to accept a handshake terminated by the attacker as an attested enclave connection. This issue is fixed in privasys-v0.5.1-go1.26.5.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/10/2026
The vulnerability identified within Privasys Go prior version 0.5.1-go1.26.5 represents a critical flaw in the implementation of Remote Attestation Transport Layer Security, commonly referred to as RA-TLS. This protocol extension is designed to establish secure communication channels where both parties verify each other's identity and integrity through cryptographic proofs generated by trusted execution environments or enclaves. In this specific context, the security model relies on binding a hardware-generated quote, which attests to the state of the enclave, to multiple distinct elements to ensure that the proof is valid only for the current session. The flaw lies in the insufficient scope of these bindings during the challenge-mode authentication process. Specifically, while the implementation correctly bound the report data from the quote to the certificate's public key and a client-generated nonce, it failed to bind this evidence to the active TLS session parameters such as the handshake transcript or ephemeral keys. This omission creates a gap in the cryptographic binding that is essential for preventing replay attacks within the context of mutual authentication.
The operational impact of this vulnerability allows an attacker who has compromised the private key associated with an enclave's identity certificate to perform a sophisticated relay attack against relying parties. By intercepting and manipulating network traffic, the attacker can capture a genuine attestation quote from a legitimate client or server during one TLS handshake. Because the quote was not cryptographically bound to that specific session's unique parameters, the attacker can reuse this valid quote in a subsequent connection attempt where they control the endpoint. The relying party, upon receiving the relayed quote and verifying it against the known public key and nonce logic, will incorrectly conclude that the new connection originates from an authentic, unmodified enclave. This effectively allows the attacker to impersonate the trusted entity without possessing the original private key for the handshake encryption, thereby bypassing the core security guarantees of RA-TLS which are intended to prevent such identity spoofing in distributed systems relying on hardware-based trust anchors.
From a classification perspective, this vulnerability aligns with CWE-294, which describes authentication bypass by capture-replay attack, as well as CWE-345 regarding insufficient verification of data authenticity. The exploitation technique maps directly to the MITRE ATT&CK tactic of Initial Access and specifically the sub-technique of Credential Replication or Relay Attacks under Defense Evasion if used for lateral movement, though primarily it constitutes a breach of integrity in the authentication phase. The failure stems from an incorrect implementation of cryptographic binding principles where session-specific entropy is not incorporated into the verification logic of the attestation proof. This type of error often arises when developers assume that nonce and key bindings are sufficient without considering the broader context of the TLS handshake state, which includes ephemeral keys exchanged during the key agreement phase that uniquely identify each connection instance.
To mitigate this vulnerability, organizations running Privasys Go must immediately upgrade to version 0.5.1-go1.26.5 or later where the binding logic has been corrected to include active session parameters in the quote verification process. For environments unable to patch immediately due to legacy constraints, network-level controls such as strict mutual TLS configurations with short-lived certificates and rigorous monitoring for anomalous handshake patterns can provide limited defense-in-depth. However, these are not substitutes for the cryptographic fix since a determined attacker with key compromise could still potentially bypass perimeter defenses if session binding remains weak at the application layer. Security teams should also audit their RA-TLS implementations to ensure that all attestation proofs are bound to both static identifiers like public keys and dynamic elements like nonces and handshake transcripts, thereby ensuring that each proof is unique to a single transaction and cannot be replayed across different sessions or connections.