Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessOperate malicious Tor relay
-
DeliveryGet selected as client's rendezvous point
-
ExploitWin rendezvous race condition
-
ExecutionImpersonate/MITM onion service
-
ImpactIntercept and tamper with client traffic
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V15 - Secure Coding and Architecture Concurrency control, locking
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the attacker to be operating a Tor relay that gets selected as the rendezvous point for the specific client-to-onion-service connection being targeted, and then to win a narrow timing race during rendezvous negotiation ('just the right circumstances,' reflected in AC:H). No authentication or user interaction is needed (PR:N/UI:N), and it is exploitable over the network (AV:N), but the practical limiters are significant: the attacker cannot freely choose which client uses their relay as rendezvous point, the vulnerable code path is a race that does not reliably trigger, and only clients/services running Tor before 0.4.9.11 (from 0.3.5.3-alpha onward) are affected. This confines realistic exploitation to targeted deanonymization/impersonation against specific onion services rather than opportunistic mass attacks. |
| Impact | This carries a high CVSS 3.1 base score of 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) driven by network reach, no authentication, a scope change, and full CIA impact - but the AC:H (high attack complexity) reflects the core limiter: the flaw is a race condition (CWE-362) that only triggers 'in just the right circumstances,' and the attacker must be operating the relay that the client selects as its rendezvous point. Real-world signals sharply temper the paper severity: EPSS is only 0.17% (7th percentile), there is no CISA KEV listing and no public exploit code identified, indicating no observed or imminent widespread exploitation. The result is a genuine cryptographic/anonymity-integrity flaw in a security-critical product that warrants prompt patching for Tor operators and onion-service hosts, but is not a mass-exploitation emergency - its exploitation is probabilistic, position-dependent (attacker must control/be-chosen-as the rendezvous point), and race-timing-sensitive, pointing to targeted deanonymization/impersonation rather than opportunistic attacks. Note a labeling tension: the vendor vector asserts A:H, yet an onion-service impersonation/MITM is fundamentally a confidentiality+integrity compromise (read and tamper with traffic) and the availability justification is weak - treat A:H as generous. |
| Exploit ScenarioDerived | An attacker runs a Tor relay and waits to be selected as the rendezvous point for a client attempting to reach a specific onion service; by winning a narrow timing race during rendezvous setup, the relay impersonates the onion service and interposes itself as a man-in-the-middle. The attacker can then present a fake service or read and tamper with the client's supposedly end-to-end-authenticated onion traffic. No public exploit code is known, and the high complexity plus required relay position make this a targeted rather than broad attack. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Sep 16, 2026
Rendezvous-point impersonation in Tor before 0.4.9.11 lets a malicious relay that a client happens to select as its rendezvous point race the rendezvous negotiation and man-in-the-middle the onion service the client was actually trying to reach, defeating the client's assurance about which service it is talking to. All Tor releases from 0.3.5.3-alpha up to and including 0.4.9.10 are affected; exploitation requires the attacker to already operate the relay chosen as the rendezvous point and to win a narrow timing window (reflected in the high attack complexity of the 9.0 base score), and no authentication or user interaction is required. No public exploit code has been identified at time of analysis and EPSS is low (0.17%, 7th percentile), so this is best treated as a targeted deanonymization/impersonation risk rather than an opportunistic mass-exploitation issue; a vendor fix is available in Tor 0.4.9.11.
Earlier versions of this analysis (1)
Man-in-the-middle impersonation of onion services in Tor before 0.4.9.11 exploits a race condition in rendezvous point circuit negotiation, allowing a malicious relay operator acting as the rendezvous point to substitute itself for the intended onion service before the legitimate service completes authentication. The flaw affects all Tor application versions prior to 0.4.9.11 across all platforms. No public exploit code or active exploitation has been identified at time of analysis, but successful exploitation yields total interception and modification of traffic the client believes is reaching a private onion service.
RemediationAI
Upgrade to Tor 0.4.9.11 or later - the vendor-released fix version documented in the upstream ChangeLog (https://gitlab.torproject.org/tpo/core/tor/-/raw/tor-0.4.9.11/ChangeLog) - applying it to both client daemons and relays and restarting the tor process so the new binary is loaded; distribution packages, Tor Browser bundles, and operator builds should be refreshed from their respective channels once they carry the 0.4.9.11 ChangeLog. There is no client-side configuration that reliably closes the race, because the attacker's advantage comes from being randomly selected as the rendezvous point rather than from a setting the client controls; pinning rendezvous points (for example with RendezvousPoints, ExcludeNodes, or StrictNodes) does narrow the pool of relays that can be used, but it shrinks the anonymity set and can itself be deanonymizing, so it should only be considered as a temporary measure for a specific high-value onion service and reverted after patching. For services that can coordinate with their users, enabling v3 onion-service client authorization lets clients reject an imposter that lacks the authorized key, at the cost of requiring key distribution and breaking anonymous public access. Until all relevant daemons are patched, treat connections to sensitive onion services from vulnerable clients as untrustworthy, and monitor the upstream ChangeLog and the NVD/VulDB advisories (https://nvd.nist.gov/vuln/detail/CVE-2026-77638, https://vuldb.com/vuln/393873) for any backports to older supported series; no public exploit code has been identified at time of analysis and EPSS is low, which makes a scheduled upgrade acceptable in most environments but not in ones that depend on onion-service identity for trust.
Affected VersionsENISA
Affected Packages
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
Tor's onion-service connection setup has a client pick an introduction point, obtain the service's chosen rendezvous point, and then build a circuit to that rendezvous point where the two circuits are joined. CVE-2026-77638 is a race condition (CWE-362) in that rendezvous negotiation: when an attacker-controlled relay is selected as the rendezvous point, a precise timing window lets it interpose itself so that the client believes it reached the intended onion service while the attacker is actually impersonating it. The CPE cpe:2.3:a:torproject:tor:*:*:*:*:*:*:*:* covers the Tor daemon itself, and the vendor ChangeLog for tor-0.4.9.11 documents the fix in the 0.4.9 maintenance line per the EUVD-derived range 0.3.5.3-alpha to <0.4.9.11. The published CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) and our independent assessment (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N) agree on network reach, high attack complexity, no privileges or user interaction, and a scope change from the relay into the client's connection, but they diverge on availability: the vendor-scored A:H is not supported by the assessed behavior, which is an impersonation/information-integrity issue rather than a denial-of-service. The core limiter in both readings is AC:H: the race 'in just the right circumstances' does not reliably trigger, and the attacker cannot choose which clients use their relay as rendezvous point.
Know when Tor 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
AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
Race condition winnable only from a chosen rendezvous relay justifies AC:H and PR:N; MITM/impersonation crosses trust boundary (S:C) with full read/tamper (C:H/I:H) but no clear availability loss (A:N).
Primary rating from Vendor (mitre).
CVSS VectorNVD
Lifecycle Timeline
4DescriptionNVD
Tor before 0.4.9.11 is prone to a race condition where in just the right circumstances a rendezvous point could man-in-the-middle (impersonate) the onion service that the client was trying to reach.
Executive ViewAI
Organizations and personnel that rely on Tor for anonymous or censorship-resistant communications face a targeted impersonation and deanonymization risk from a critical flaw in Tor before 0.4.9.11. A successful attack could undermine trust in the identity of the onion service being reached and expose sensitive user relationships or activities, though it requires an adversary to control the selected rendezvous relay and win a narrow timing window. Leadership should prioritize patching any Tor-dependent systems and at-risk user endpoints because the flaw affects confidentiality assurances central to Tor's business use cases; no public exploit identified at time of analysis.
Apply vendor patch.
Threat Intelligence Overview
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.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Race conditions occur when multiple concurrent requests exploit the brief time gap between checking a condition and acting upon it (TOCTOU - Time of Check, Time of Use).
Tor Browser before 7.0.9 on macOS and Linux allows remote attackers to bypass the intended anonymity feature and discove
Tor before 0.3.5.16, 0.4.5.10, and 0.4.6.7 mishandles the relationship between batch-signature verification and single-s
A use-after-free issue was discovered in Tor 0.3.2.x before 0.3.2.10. Rated high severity (CVSS 7.5), this vulnerability
The SafeSocks option in Tor before 0.4.7.13 has a logic error in which the unsafe SOCKS4 protocol can be used but not th
Out-of-bounds write in The Tor Project's tor daemon (0.2.8.2-alpha through versions before 0.4.9.9) can be triggered whe
The daemon in Tor through 0.4.1.8 and 0.4.2.x through 0.4.2.6 does not verify that a rendezvous node is known before att
Write-after-free in Tor's conflux (traffic-splitting) subsystem allows a remote unauthenticated attacker to crash a Tor
Use-after-free in Tor's conflux circuit handling allows a malicious Tor client to corrupt relay memory by sending a RELA
In Tor before 0.2.5.16, 0.2.6 through 0.2.8 before 0.2.8.17, 0.2.9 before 0.2.9.14, 0.3.0 before 0.3.0.13, and 0.3.1 bef
Tor before 0.2.8.12 might allow remote attackers to cause a denial of service (client crash) via a crafted hidden servic
Tor before 0.2.8.9 and 0.2.9.x before 0.2.9.4-alpha had internal functions that were entitled to expect that buf_t data
The hidden-service feature in Tor before 0.3.0.8 allows a denial of service (assertion failure and daemon exit) in the r
EUVD-2026-63647
GHSA-pq38-gw56-4w65
NVD
CVE.org
EPSS
VulDB
Exploit-DB