Privasys rustls CVE-2026-108266

Exploitation requires the attacker to already possess a genuine enclave's TLS private key - without that key the relay cannot be mounted (this is the AT:P attack requirement and a primary limiting factor). It applies only to RA-TLS deployments using the Privasys rustls fork prior to privasys-v0.8.1, where the attestation quote's ReportData is bound to the client certificate public key and client nonce but not to the live TLS session. The remediation adds a 32-byte channel binder derived from the TLS 1.3 handshake key schedule, so the weakness is specific to the TLS 1.3 RA-TLS client-attestation path; AC:H reflects the additional effort of relaying a valid quote onto a separate attacker-terminated connection.

The CVSS 4.0 base score of 9.1 (Critical) is driven by network reach (AV:N), no required privileges (PR:N), no user interaction (UI:N), and high confidentiality and integrity impact (VC:H/VI:H), but it is importantly tempered by AC:H and AT:P - the vector itself encodes that exploitation is hard and carries a specific attack requirement. That requirement is stated plainly in the description: the attacker must FIRST possess a genuine enclave's TLS private key before the relay is possible, which is a substantial precondition that does not exist in default/benign conditions. No EPSS score, CISA KEV listing, SSVC decision, or public POC was provided in the input, so there is no evidence of active or automatable exploitation; this is a high-CVSS issue whose real-world risk is gated by the key-possession prerequisite rather than a broadly sprayable remote flaw. CWE-346 (origin validation) and the mechanism (accepting an attacker-terminated connection as the attested enclave) indicate the true nature is an attestation/relay spoofing weakness, even though the single input Tag labels it 'Information Disclosure'; the VC:H/VI:H split is consistent with both impersonation and resulting data exposure. Net: a serious design flaw in confidential-computing attestation that warrants prompt patching for anyone running this fork, but not a mass-exploitation emergency given the private-key precondition and absence of exploitation signals.

An attacker who has already obtained a legitimate enclave's TLS private key (for example via key extraction or a separate compromise) initiates or terminates a TLS connection to a relying party and replays a genuine, valid RA-TLS attestation quote whose ReportData was bound only to the certificate public key and client nonce. Because the quote does not commit to the specific TLS session, the relying party accepts the attacker-controlled endpoint as the genuinely attested enclave. No public exploit was identified in the provided data.