RA-TLS Clients CVE-2026-108269

Exploitation is gated by three concrete prerequisites, all drawn from the description and commit evidence: (1) the client must be running in CHALLENGE mode - deterministic mode does not use the nonce/session binding and the commit shows deterministic mode ignores the binder, so it is not affected; (2) the deployment must use the Privasys TLS fork that exposes the RA-TLS channel binder - the standard Go build (challenge_std.go) returns a nil binder and cannot even offer challenge mode, so stock builds are out of scope; and (3) the attacker must already hold a valid enclave TLS private key and be positioned to relay a genuine quote onto a separate, attacker-terminated connection. Affected versions are all releases prior to 0.5.0 of privasys/ra-tls-clients (Rust and Go verifiers). The private-key-possession requirement is the dominant limiting factor and is the reason for the CVSS AC:H/AT:P metrics.

The input CVSS 4.0 base score is 9.1 (Critical), driven by AV:N with VC:H/VI:H (full session confidentiality and integrity loss) - but the same vector carries AC:H and AT:P, signalling high attack complexity and a mandatory attack precondition. That precondition is explicit in the description: the attacker must already possess a genuine enclave TLS private key before any relay is possible, which is a very high bar that sharply lowers real-world likelihood relative to the headline score. No EPSS probability, CISA KEV listing, or POC indicator was supplied in the intelligence set, so there is no evidence of active or probable exploitation - no public exploit identified at time of analysis. Net: this is a legitimately severe attestation-trust bypass (a stolen key lets an attacker impersonate an attested enclave and MITM the application channel), but it is a conditional, targeted risk rather than a mass-exploitation threat. Prioritize urgently only for deployments running the vulnerable client in challenge mode on the Privasys TLS fork; treat it as lower urgency elsewhere. Note: EPSS/KEV/POC signals are absent from the input and cannot be inferred.

An attacker who has extracted or otherwise obtained an enclave's TLS private key stands up a rogue endpoint and relays a legitimate, still-valid attestation quote - one bound only to the certificate public key and client nonce, not to the live TLS session - to a RA-TLS challenge-mode client. The client accepts the attacker-terminated connection as the genuine attested enclave and begins exchanging application traffic the attacker can read and manipulate. No public exploit identified at time of analysis.