Privasys ra-tls-clients CVE-2026-108362

Exploitable only against Privasys ra-tls-clients verifiers prior to 0.11.0 that use the default policy with no platform allow-list (AllowedPlatformIDs / allowed_platform_ids empty), because such verifiers accept valid TEE measurements from any unrevoked platform without checking which machine produced them. The attacker must either forge TEE attestation evidence or extract attestation secrets from a separate compromised-but-still-unrevoked TEE platform (Intel SGX/TDX or AMD SEV-SNP) and present valid measurements from it - this requirement is what drives the CVSS AC:H and AT:P ratings. Exploitation is LIMITED by the need to possess a genuine unrevoked platform or forge evidence, and is fully mitigated by upgrading to 0.11.0 and pinning expected machines via AllowedPlatformIDs, which fails closed when no platform identity is reported and is additionally backed by PCK/CRL revocation checking.

This is a genuine high-severity design flaw rather than an inflated CVSS score, but its real-world exploitability is gated by demanding preconditions. The only signal available is the CVSS 4.0 vector (9.1 Critical: AV:N/AC:H/AT:P/PR:N/UI:N with high confidentiality and integrity impact, no availability or subsequent-system impact) - there is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis. The vector's AC:H and AT:P (attack requirements present) correctly reflect that exploitation is not trivial: an attacker must either forge valid TEE attestation evidence or extract attestation secrets from a separate compromised-but-unrevoked TEE platform, which is a substantial barrier. The PR:N/UI:N combination means that once those preconditions are met, no authentication or victim interaction is needed, so a capable attacker who already controls a genuine unrevoked SGX/TDX/SEV-SNP machine can impersonate the attested endpoint and defeat the entire trust guarantee of attested TLS. In short, the signals are internally consistent - high impact, network reachable, but high attack complexity with specific attack requirements - pointing to a flaw that matters greatly to the narrow set of confidential-computing deployments that use this library, while being far from mass-exploitable. No KEV/EPSS/POC data is present, so there is no evidence of active or opportunistic exploitation.

An attacker who operates (or has compromised) a genuine, unrevoked TEE platform presents valid attestation evidence from that machine to a Privasys ra-tls-clients verifier that has not pinned platform identities. Because versions prior to 0.11.0 accept correct measurements from any unrevoked platform regardless of which machine produced them, the verifier treats the attacker's endpoint as the intended Attester, letting the attacker impersonate the attested TLS endpoint and intercept or manipulate the session. No public exploit code is known; exploitation requires either forging evidence or controlling a legitimate unrevoked TEE platform.