Privasys Go EUVD-2026-96017

Exploitation requires challenge-mode RA-TLS to be in use and, critically, the attacker must already possess a valid enclave TLS private key - the quote's report_data was computed as SHA-512(public_key_sha256 || nonce) with no binding to the live TLS session, so a holder of that key can replay a genuine quote on a different connection. It further requires a relying party / verifier that does not independently bind attestation to the session channel. Limiting factors: the stolen-private-key prerequisite (reflected in AC:H/AT:P) sharply narrows who can exploit this; the fix adds an HKDF-derived 32-byte session binder (privasys-ratls-binder-v1) so that binding-aware verifiers fail closed, and TLS 1.2 is fail-closed by design.

The input CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N, base 9.1) accurately captures a high-impact but high-bar flaw. The network attack vector and PR:N are counterbalanced by AC:H and AT:P, which encode the central precondition stated in the description: the attacker must already possess a genuine enclave TLS private key. This is a privilege-escalation-of-trust / origin-validation issue (CWE-346), not a wormable RCE. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so the realistic status is 'no public exploit identified at time of analysis'; the only exploit-relevant artifact is the fix commit itself. The signals are internally consistent rather than conflicting - a very high CVSS is tempered by a demanding prerequisite (a stolen enclave key) and by the niche deployment footprint of a Go fork. Net assessment: this is a genuine correctness/security defect in the attestation-binding logic that matters acutely to the small population of confidential-computing operators using challenge-mode RA-TLS, but it is NOT a broad, opportunistically-exploitable internet threat. Prioritize if you run Privasys Go enclaves; otherwise low urgency. Note: with no EPSS/KEV/POC data supplied, exploitation-likelihood signals are absent rather than low - treat 'no exploit' as unconfirmed availability, not as proof of difficulty.

An attacker who has extracted or otherwise obtained an enclave's TLS private key relays a legitimate, freshly-generated attestation quote (bound only to the public key and client nonce) onto a separate TLS connection that the attacker terminates. The relying party verifies the quote as valid and accepts the attacker-controlled endpoint as a genuine attested enclave, trusting it with sensitive data or commands. No public exploit code was identified; exploitation also requires the victim verifier to be unaware of the new session-channel binding.