New releases:,, and (with security fixes!)

by nickm | March 18, 2020

We have new releases today. If you build Tor from source, you can download the source code for from the download page on the website. Packages should be available within the next several days, including a new Tor Browser.

This is the third stable release in the 0.4.2.x series. It backports numerous fixes from later releases, including a fix for TROVE-2020-002, a major denial-of-service vulnerability that affected all released Tor instances since Using this vulnerability, an attacker could cause Tor instances to consume a huge amount of CPU, disrupting their operations for several seconds or minutes. This attack could be launched by anybody against a relay, or by a directory cache against any client that had connected to it. The attacker could launch this attack as much as they wanted, thereby disrupting service or creating patterns that could aid in traffic analysis. This issue was found by OSS-Fuzz, and is also tracked as CVE-2020-10592.

We do not have reason to believe that this attack is currently being exploited in the wild, but nonetheless we advise everyone to upgrade as soon as packages are available.

We're also releasing updates for our older supported series.  You can find the source code for and from our distribution site at You can also read the ChangeLog and the ChangeLog.

There's also a new alpha, described in the previous blog post.

Changes in version - 2020-03-18

  • Major bugfixes (security, denial-of-service, backport from
    • Fix a denial-of-service bug that could be used by anyone to consume a bunch of CPU on any Tor relay or authority, or by directories to consume a bunch of CPU on clients or hidden services. Because of the potential for CPU consumption to introduce observable timing patterns, we are treating this as a high-severity security issue. Fixes bug 33119; bugfix on Found by OSS-Fuzz. We are also tracking this issue as TROVE-2020-002 and CVE-2020-10592.
  • Major bugfixes (circuit padding, memory leak, backport from
    • Avoid a remotely triggered memory leak in the case that a circuit padding machine is somehow negotiated twice on the same circuit. Fixes bug 33619; bugfix on Found by Tobias Pulls. This is also tracked as TROVE-2020-004 and CVE-2020-10593.


  • Major bugfixes (directory authority, backport from
    • Directory authorities will now send a 503 (not enough bandwidth) code to clients when under bandwidth pressure. Known relays and other authorities will always be answered regardless of the bandwidth situation. Fixes bug 33029; bugfix on
  • Minor features (continuous integration, backport from
    • Stop allowing failures on the Travis CI stem tests job. It looks like all the stem hangs we were seeing before are now fixed. Closes ticket 33075.
  • Minor bugfixes (bridges, backport from
    • Lowercase the configured value of BridgeDistribution before adding it to the descriptor. Fixes bug 32753; bugfix on
  • Minor bugfixes (logging, backport from
    • If we encounter a bug when flushing a buffer to a TLS connection, only log the bug once per invocation of the Tor process. Previously we would log with every occurrence, which could cause us to run out of disk space. Fixes bug 33093; bugfix on
  • Minor bugfixes (onion services v3, backport from
    • Fix an assertion failure that could result from a corrupted ADD_ONION control port command. Found by Saibato. Fixes bug 33137; bugfix on This issue is also tracked as TROVE-2020-003.
  • Minor bugfixes (rust, build, backport from
    • Fix a syntax warning given by newer versions of Rust that was creating problems for our continuous integration. Fixes bug 33212; bugfix on
  • Testing (Travis CI, backport from
    • Remove a redundant distcheck job. Closes ticket 33194.
    • Sort the Travis jobs in order of speed: putting the slowest jobs first takes full advantage of Travis job concurrency. Closes ticket 33194.
    • Stop allowing the Chutney IPv6 Travis job to fail. This job was previously configured to fast_finish (which requires allow_failure), to speed up the build. Closes ticket 33195.
    • When a Travis chutney job fails, use chutney's new "" tool to produce detailed diagnostic output. Closes ticket 32792.


Please note that the comment area below has been archived.

March 18, 2020


Why can't you publish this vulnerability AFTER you upload all necessary packages?
Not all people compile from source. In fact they just apt update only.

The team that makes the source code is not the same team that makes the packages-- in fact, most of our packages are made by volunteers. By the time all the packagers have the source, the source is generally out there. Many other projects have found that trying to keep a vulnerability secret until everybody can build packages tends to result in more leaks than than they've desired.

We've been talking about when, if ever, we'd try to get the source out to "packagers only" ahead of public disclosure -- if we did something like that, it would probably be reserved for something even worse than DoS: maybe if we found a remote code execution bug or something.

Have a look at our current draft security policy for more info about how we handle this stuff.

March 20, 2020


Since many years ago we were connecting to Tor using InvizBox routers. Since you publish this update all the InvizBox and (OpenWrt) similar routers are crashing. The update in the routers' firmware will take even months, until then all us have no other choice to stay offline.
I cannot find the words to describe this tremendous mess in the middle of a pandemic with all the people locked up in their homes.

Write a bug report to OpenWrt asking them to update their package:

As of today (2020-03-24),
OpenWrt 19.07.2 (current stable) package repository feed is at tor version (2019-12-09).
OpenWrt 18.06.8 (old stable) package repository feed is at tor version (2019-09-19).