See how tor project compares to other vendors in security performance
tor before 0.4.9.9 was prone to an infinite loop when decompressing a truncated zlib/gzip stream with done=1. A truncated stream never reaches ZSTREAMEND, causing zlib to return ZBUFERROR with no input remaining, which bufaddcompress() mistook for a full output buffer and retried forever. Fixed by returning TORCOMPRESSERROR in that case so the caller can abort cleanly. This is TROVE-2026-021.
Tor before 0.4.9.9 was prone to a compression bomb bypass where an attacker could concatenate many gzip or zlib sub-streams, each just under the per-stream detection threshold, to avoid the compression bomb check entirely. This is TROVE-2026-022.
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.
Tor before 0.4.9.10 did not reject a CONFLUXLINK cell that arrives on a circuit which already has attached streams. A malicious client could send a RELAYCOMMANDBEGIN before the CONFLUXLINK on the same circuit, attaching an exit stream that would later end up orphan leaving a dangling circuit back-pointer and a use-after-free (UAF) when the circuit is freed. This is TROVE-2026-025.
Tor before 0.4.9.7 has an out-of-bounds read by one byte via a malformed BEGIN cell, aka TROVE-2026-007.
Tor before 0.4.9.7 has a NULL pointer dereference when a CERT cell is received out of order, aka TROVE-2026-006.
Tor before 0.4.9.7, when circuit queue memory pressure exists, can experience a client crash because of a double close of a circuit, aka TROVE-2026-009.
Tor before 0.4.9.7 mishandles accounting of the conflux out-of-order queue during the clearing of a queue, aka TROVE-2026-010.
Tor before 0.4.9.7 can attempt or accept BEGINDIR via conflux legs, aka TROVE-2026-008.
Tor before 0.4.9.7 has an out-of-bounds read when an END, a TRUNCATE, or a TRUNCATED cell lacks a reason in its payload, aka TROVE-2026-011.
From diffing 0.4.9.6 and 0.4.9.7 [0]: +Changes in version 0.4.9.7 - 2026-05-06 + This is a security release fixing several major bugfixes that were reported + in the past weeks. Huge thanks to everyone that reported these issues! We + strongly recommend upgrading as soon as possible. + + o Major bugfixes (cell handling): + - Fix out-of-bounds read (OOB) when END, TRUNCATE and TRUNCATED cell + have no reason in their payload. TROVE-2026-011. Found by Found by + Brian Carpenter (geeknik). Fixes bug 41254; bugfix + on 0.1.1.1-alpha. + + o Major bugfixes (conflux): + - Do not attempt or accept BEGINDIR via conflux legs. TROVE-2026- + 008. Credit to Anas Cherni from Calif.io in collaboration with + Claude and Anthropic Research. Fixes bug 41243; bugfix + on 0.4.8.1-alpha. + + o Major bugfixes (conflux, relay): + - Adjust conflux out-of-order queue accounting when clearing a + queue. TROVE-2026-010. Found by aptupdate. Fixes bug 41251; bugfix + on 0.4.8.1-alpha. + + o Major bugfixes (pathbias): + - Fix a client-side crash caused by double-close of a circuit while + under circuit queue memory pressure. TROVE-2026-009. Found by + cypherpunks. Fixes bug 41237; bugfix on 0.3.3.6-rc. + + o Major bugfixes (relay): + - Fix null pointer dereference when receiving a CERT cell out of + order. TROVE-2026-006. Found by Fwame. Fixes bug 41240; bugfix + on 0.2.4.4-alpha. + + o Major bugfixes (relay, onion service): + - Fix off-by-one out-of-bounds read if a malformed BEGIN cell is + received. TROVE-2026-007. Found by Flanagan. Fixes bug 41245; + bugfix on 0.2.4.7-alpha. + + o Minor features (fallbackdir): + - Regenerate fallback directories generated on May 06, 2026. + + o Minor features (geoip data): + - Update the geoip files to match the IPFire Location Database, as + retrieved on 2026/05/06. +
The referenced bugs are private, so no more details are available yet. There were several recent other security releases too for Tor.
[0] https://gitlab.torproject.org/tpo/core/tor/-/blob/tor-0.4.9.7/ReleaseNotes#L5
A security flaw has been discovered in Tor up to 0.4.7.16/0.4.8.17. Impacted is an unknown function of the component Onion Service Descriptor Handler. Performing manipulation results in resource consumption. The attack may be initiated remotely. The attack's complexity is rated as high. The exploitability is considered difficult. Upgrading to version 0.4.8.18 and 0.4.9.3-alpha is recommended to address this issue. It is recommended to upgrade the affected component.
A Denial of Service issue was fixed in tor 0.4.7.8 related to congestion control. RTT estimation can become wedged, seriously degrading congestion control performance on all circuits. This impacts clients, onion services, and relays, and can be triggered remotely by a malicious endpoint.
References: https://gitlab.torproject.org/tpo/core/tor/-/issues/40626 https://lists.torproject.org/pipermail/tor-announce/2022-June/000242.html https://github.com/torproject/tor/commit/5a25374209689466e10906a77e66ad717a615a02 https://github.com/torproject/tor/commit/b0496d40197dd5b4fb7b694c1410082d4e34dda6
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 before 0.3.1.9, the replay-cache protection mechanism is ineffective for v2 onion services, aka TROVE-2017-009. An attacker can send many INTRODUCE2 cells to trigger this issue.
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 before 0.3.1.9, remote attackers can cause a denial of service (NULL pointer dereference and application crash) against directory authorities via a malformed descriptor, aka TROVE-2017-010.
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 before 0.3.1.9, an attacker can cause a denial of service (application hang) via crafted PEM input that signifies a public key requiring a password, which triggers an attempt by the OpenSSL library to ask the user for the password, aka TROVE-2017-011.
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 before 0.3.1.9, there is a use-after-free in onion service v2 during intro-point expiration because the expiring list is mismanaged in certain error cases, aka TROVE-2017-013.
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 before 0.3.1.9, relays (that have incompletely downloaded descriptors) can pick themselves in a circuit path, leading to a degradation of anonymity, aka TROVE-2017-012.
Tor Browser before 7.0.9 on macOS and Linux allows remote attackers to bypass the intended anonymity feature and discover a client IP address via vectors involving a crafted web site that leverages file:// mishandling in Firefox, aka TorMoil.
Upstream issue:
https://trac.torproject.org/projects/tor/ticket/24052
References:
https://blog.torproject.org/tor-browser-709-released https://www.bleepingcomputer.com/news/security/tormoil-vulnerability-leaks-real-ip-address-from-tor-browser-users/ https://www.wearesegment.com/research/tormoil-torbrowser-unspecified-critical-security-vulnerability/
It was reported [1],[2] that Tor suffered from a denial of service vulnerability due to an error when handling SENDME cells. This could be exploited to cause excessive consumption of memory resources within an entry node.
This is fixed in upstream version 0.2.3.25 (git [3]).
[1] https://secunia.com/advisories/51329/ [2] https://trac.torproject.org/projects/tor/ticket/6252 [3] https://gitweb.torproject.org/arma/tor.git/commitdiff/b9b54568c0bb64c32bd0b362954bdbc8c1234b16
A vulnerability in Tor was reported [1] that could allow a malicious remote attacker to cause a denial of service. This vulnerability is due to a boundary error within the policysummarize() function in src/or/policies.c which can be exploited to crash a Tor directory authority.
Upstream announced the release of 0.2.1.30 [2] that is noted to correct this flaw.
[1] http://secunia.com/advisories/43548/ [2] https://lists.torproject.org/pipermail/tor-announce/2011-February/000000.html