Skip to main content

Privasys ra-tls-clients CVE-2026-108361

| EUVDEUVD-2026-97782 HIGH
Time-of-check Time-of-use (TOCTOU) Race Condition (CWE-367)
2026-10-12 GitHub_M
7.2
CVSS 4.0 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Obtain local access to Attester endpoint
  2. Delivery
    Wait for attested TLS connection to establish
  3. Exploit
    Modify workload code/data within connection window
  4. Execution
    Verifier continues trusting stale initial evidence
  5. Impact
    Tamper runtime state and exfiltrate data

Vulnerability Assessment

Weakness
CWE
ASVS 5.0
V15 - Secure Coding and Architecture TOCTOU prevention
Exploitation Conditions

Exploitation requires the attacker to already hold local, low-privilege access on the host serving as the Attester (the TLS endpoint being attested), AND an attested connection (deterministic or challenge mode) that has already been successfully appraised and established. The attacker must then modify the workload's code, data, or configuration during the live window between connection establishment and termination - this timing constraint is exactly what the CVSS AT:P (Attack Requirements: Present) flag encodes. Limiting factors that reduce real-world risk: no network-remote path (AV:L - the attacker needs local presence on the Attester), low-but-nonzero privilege is still needed (PR:L), the attack only succeeds against an active connection and ends when it terminates, and only versions before 0.9.1 are affected. 'none' (unattested) connections are not in scope for this attested-state trust break.

Impact

This is CWE-367 (TOCTOU) in a remote-attestation TLS library: attestation is performed once at connection establishment, and the verifying peer keeps trusting that initial state for the connection's lifetime, so a locally-positioned attacker can mutate the Attester's workload after appraisal. The provided CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:L/UI:N, VC:H/VI:H/VA:N, score 7.2 / HIGH) is internally consistent with the description: exploitation is LOCAL (AV:L) on the Attester endpoint, requires low privileges (PR:L), and depends on a timing window captured by AT:P (Attack Requirements present) - the attacker must act within the live connection window. No EPSS score, no CISA KEV listing, and no public exploit were supplied; the GitHub references are the fix (advisory GHSA-gg8q-mfhh-wrrc and remediation commits), NOT exploit code, so this should be read as a patch-driven disclosure rather than an actively-exploited threat. Signals are broadly aligned (local vector + privilege requirement + niche product all point to low widespread risk); the one tension worth noting is the 'Information Disclosure' tag versus a root cause that is fundamentally an integrity/TOCTOU weakness - treat confidentiality impact (VC:H) as secondary to the runtime integrity break (VI:H). Net: a legitimate HIGH-severity design flaw for the specific confidential-computing deployments that rely on this library, but not a broad-fleet emergency given the local vector and narrow deployment footprint.

Exploit ScenarioDerived

An attacker who already has local access to a host acting as the Attester waits until a verifying peer has successfully appraised the Evidence and established the attested TLS connection. During the live connection the attacker modifies the workload's code, data, or configuration; because the library attested only once at setup, the peer keeps treating the (now stale) initial Evidence as current and continues trusting the compromised endpoint. No public exploit code was identified at time of analysis.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 12, 2026

Time-of-check/time-of-use weakness in Privasys ra-tls-clients before 0.9.1 allows a local, low-privileged attacker on the attested TLS endpoint (the Attester) to modify workload code, data, or configuration after remote attestation has already succeeded, while the verifying peer continues to trust the original Evidence for the remainder of the connection. Exploitation requires prior local access to the Attester plus an attested connection (deterministic or challenge mode) that is still open - the window spans connection establishment to termination, and unattested ('none') connections are out of scope. The flaw is fixed in 0.9.1; no public exploit identified at time of analysis.

RemediationAI

Upgrade Privasys ra-tls-clients to 0.9.1, the exact version in which the single-shot attestation behavior is corrected; the vendor advisory is at https://github.com/Privasys/ra-tls-clients/security/advisories/GHSA-gg8q-mfhh-wrrc, with the corresponding upstream fixes in commits 076074873117ee5ff35a7c39e02952c28de3df0c, 5ccfd778132e17cb54bb1a9c7b89d57fcfea59ec, and b9114d772a636ad3307957dde4bb8afe70c9b40d (the visible diff adds a TrustSelection/verifyServerChain trust-anchor policy in the Go SDK). If immediate upgrade is not possible, bound the exposure window by terminating and re-establishing attested connections frequently rather than holding long-lived sessions, and have the verifying peer re-appraise Evidence periodically instead of trusting the initial appraisal - both add handshake and attestation overhead, so tune lifetimes to the sensitivity of the workload. Reinforce the local-access prerequisite by strictly limiting interactive access and hardening the Attester host (least-privilege accounts, no unnecessary local shells, file-integrity monitoring over workload code, data, and configuration paths), since the attack inherently requires an attacker already resident on that endpoint; note that these are compensating controls only and do not restore the integrity guarantee that 0.9.1 provides. Never disable attestation verification or downgrade an attested connection to public-PKI-only trust as a workaround.

Affected VersionsENISA

ra-tls-clients < 0.9.1

Affected Packages

euvd ra_tls_clients fix: 0.9.1

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

CWE-367 (Time-of-check Time-of-Use) in a remote-attestation TLS library. RA-TLS binds a TLS session to cryptographic attestation Evidence (e.g., an enclave quote) so that a verifier can tie a peer's public key to a measured workload state. In ra-tls-clients before 0.9.1, Evidence was appraised exactly once, at connection establishment, and the verifying peer treated that measurement as valid for the entire lifetime of the connection, with no re-appraisal or continuous binding to the running workload. The result is a classic TOCTOU gap: after the check passes, a locally positioned attacker can alter the Attester's runtime state and the peer's trust decision remains stale. The supplied Go source diff shows the upstream fix work restructures the client's chain-verification path, adding a TrustSelection policy (auto/fleet/public) and a new verifyServerChain callback in go/ratls/client.go and go/ratls/trust.go so that an attested connection must chain to the fleet anchors (or caller-supplied CA) rather than an arbitrary public-PKI certificate; this is the trust-anchor hardening referenced by the advisory, which also states the connection-lifetime attestation issue itself is resolved in 0.9.1. CVSS 4.0 vector AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N indicates the attack is local, requires the additional precondition of an established attested connection (AT:P), needs low privileges, and yields high confidentiality and integrity impact on the vulnerable system without availability impact. The independent assessment rates this at AV:L/AC:H/PR:L/UI:N/C:H/I:H/A:N under CVSS 3.1.

Know when Ra Tls Clients gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 7.2 HIGH
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
vuln.today AI 6.3 MEDIUM

Local to the Attester (AV:L), low-privilege foothold needed (PR:L), and a race/timing window within the live connection maps to AC:H; integrity and confidentiality broken (C:H/I:H), no availability loss.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
4.0 AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Local
Attack Complexity
Low
Attack Requirements
Present
Privileges Required
Low
User Interaction
None
Vulnerable system: Confidentiality
High
Vulnerable system: Integrity
High
Vulnerable system: Availability
None
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

Lifecycle Timeline

2
Patch available
Oct 12, 2026 - 20:18 EUVD
CVE Published
Oct 12, 2026 - 19:06 cve.org
HIGH 7.2

DescriptionCVE.org

Privasys Remote Attestation TLS Clients provides multi-language utilities for verifying attested TLS connections. Before 0.9.1, an attacker with local access could modify workload code, data, and configuration at any time after successful connection establishment. Once Evidence was successfully appraised and the connection was established, there was a window of vulnerability from the establishment of the connection to the termination of the connection where an attacker could modify the state of the workload and platform at runtime on the TLS endpoint acting as the Attester. This vulnerability was possible because Privasys/ra-tls-clients performed attestation only once in the lifetime of the connection (at connection establishment time), and the verifying peer continued to believe that the state was the same as in the initial Evidence throughout, whereas it could be stale at some point in time. This vulnerability is fixed in 0.9.1.

Executive ViewAI

Why It Matters

Privasys ra-tls-clients versions prior to 0.9.1 contain a time-of-check/time-of-use vulnerability that allows a local, low-privileged attacker on an attested TLS endpoint to modify workload code, data, or configuration after remote attestation has succeeded, while the verifying peer continues to trust the original evidence. Organizations relying on remote attestation for workload integrity are affected, particularly those in multi-tenant or shared environments where local access is less controlled. Leadership should care because this undermines the trust model of attested connections, potentially leading to data tampering or unauthorized code execution within trusted workloads, though no public exploit has been identified.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.1%
Top 100% exploitable
Prevalence
Rare
obscure open-source attestation SDK, minimal production deployment footprint
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.1%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact
High

Priority Score

36
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +36
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy