Circuit-building DoS wave: 20x peak, 8x sustained circuits on guard relays since Jun 25
Summary: - Our guard relay family has been under a sustained circuit-building DoS wave since 2026-06-25 23:00 UTC, still ongoing: open circuits at 20x peak and 8x sustained, onionskin load 7x, stream creation 12x -- but bandwidth only +20%. Millions of near-idle circuits. See the attached charts (fleet open circuits, onionskin processing, and bandwidth, Jun 10 - Jul 10). - Every location and provider we run (EU + NA) was hit simultaneously with the same onset time, and the load arrives over existing OR connections (established TCP counts stayed flat). There is an onion-service introduction component. Looks network-wide or family-targeted, not host-specific. - Impact contained so far: tor's DoS defenses engaged, brief onionskin drops on a small subset of relays, consensus flags dipped ~5%, zero TCP port exhaustion and zero global rate-limit events. - EU servers shed 10-20% of real traffic, which are commonly closer to capacity, while NA absorbed more and have never been at capacity. - Jun 25 - Jul 10, full event window vs prior 15 days: open circuits +719% (the 8x sustained figure), onionskins processed +639%, stream creation +1126%, bandwidth +20% Details, chronological (times UTC; metrics from MetricsPort, fleet-wide): - Jun 22, 12:00-24:00 -- 12h precursor burst: open circuits ~8x normal, then two quiet days. - Jun 25, 23:00 -- onset: onionskin processing ~2.5x within 30 minutes; open circuits ~6x within 3 hours. - Jun 26-27 -- first major waves: introduce2_rejected bursts an order of magnitude above normal (peak Jun 27 03:00); conn_rejected ~5x baseline with bursts to ~10x. - Jun 26-28 -- overload symptoms: brief onionskin drops on a small subset of relays; tor's OOM handler ~10x more active; Stable/Fast/Running flag counts dip ~5% (Guard -3%). - Jul 5, 08:00 -- the 20x peak: open circuits hit ~20x baseline, the event's maximum so far. - Jul 6-10 -- slow decay: still ~5-6x baseline as of Jul 10. The symptom class matches the 2022-2023 network DDoS -- circuit creation floods overloading non-exit relays' onionskin processing, plus an onion-service introduction component: https://forum.torproject.org/t/tor-relays-dos-attacks-status-update/5333 https://blog.torproject.org/tor-network-ddos-attack/ Metrics to compare on your relays: tor_relay_circuits_total{state="opened"} tor_relay_load_onionskins_total tor_relay_streams_total tor_relay_dos_total (by type) Is anyone else seeing this since Jun 25? Happy to share more detail.
On 7/10/26 18:44, Tor at 1AEO via tor-relays wrote:
Summary: - Our guard relay family has been under a sustained circuit-building DoS wave since 2026-06-25 23:00 UTC, still ongoing: open circuits at 20x peak and 8x sustained, onionskin load 7x, stream creation 12x -- but bandwidth only +20%. Millions of near-idle circuits. See the attached charts (fleet open circuits, onionskin processing, and bandwidth, Jun 10 - Jul 10). - Impact contained so far: tor's DoS defenses engaged, brief onionskin drops on a small subset of relays, consensus flags dipped ~5%, zero TCP port exhaustion and zero global rate-limit events.
<...> Is anyone else seeing this since Jun 25? Happy to share more detail.
I run the non-exit relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3 I have seen weird circuit behavior since about July 1st. Number of circuits are much higher than normal, about 120k instead of 80k. Every 2 hours, on the hour, the number of circuits drops before quickly climbing back to the high level. What do you mean by "tor's DoS defenses engaged"? The automatic ones or something of your own? Tor Bw and circuits
@Logforme — stock defenses, nothing custom: Tor's built-in DoS subsystem, driven by consensus parameters every relay applies by default (a source holding a second connection may create circuits at 2/sec with a burst of 60, and keep at most 50 concurrent connections per tor process). You can watch them fire in tor_relay_dos_total (via Tor MetricsPort). Your ~1.5x is consistent with the same flood — intensity varies hugely by position and weight, and our guard-only fleet sits at the extreme end. We haven't looked for a 2-hour periodicity; our circuits recede and resurge on a multi-day scale. What's firmed up since my first mail: * Three attacks offset in time, not one: an onion-service INTRODUCE2 flood (peaked Jun 27, then collapsed), the main circuit-creation flood (onionskins peaked Jun 29 at ~11.5x, ~97% ntor_v3; open circuits Jul 5 at ~20x), and since Jul 5 malformed, protocol-violating circuits — tor_relay_circ_proto_violation_total surged >150x, peaked Jul 6, still running at dozens of times baseline. * Network-wide, in the public archives: relays signing overload-general climbed from a 2–3% baseline to 8.2% on Jun 28, then a second wave to 12.2% (1,254 relays) on Jul 12. It lands on guards: guard-only overload hit ~17.7% by Jul 12 while pure exits stayed far lower. Running-flag churn roughly tripled — ~5,900 distinct relays flapped Running at least twice vs ~2,000 in an equal pre-flood window: saturated relays failing reachability probes while still relaying, not going down. * The cost to absorb it: busiest hosts pegged at 90–99% CPU for two weeks (raw ntor cost), resident memory ~2.5x fleet-wide (~8x on the worst relays) with kernel OOM kills on the hardest-hit hosts (every process auto-restarted), and real onionskin drops only on our smallest host (7.6% of its own load; zero everywhere else). Refinements to my first mail: onionskins settled at 6.3x avg / 11.5x peak, streams 2.5x avg / 6.0x peak (the early 7x/12x were point-in-time reads). Full write-up in four posts — every number is an aggregate counter or reproducible from CollecTor/Onionoo: * Network-wide picture, public data alone: https://1aeo.com/blog/tor-network-dos-wave-june-2026.html * Anatomy of the attack (the three waves): https://1aeo.com/blog/circuit-building-dos-anatomy-june-2026.html * What absorbing it costs an operator: https://1aeo.com/blog/circuit-building-dos-fleet-cost-june-2026.html * Measurement traps + what Tor could change: https://1aeo.com/blog/defending-against-circuit-dos-june-2026.html Chart-reproduction scripts: https://github.com/1aeo/1aeo-blog-charts Attached: the three waves in one picture, Tor's defenses firing per vector, and the network-wide overload curve. On Monday, July 13th, 2026 at 12:56 PM, Logforme via tor-relays <tor-relays@lists.torproject.org> wrote:
On 7/10/26 18:44, Tor at 1AEO via tor-relays wrote:
Summary: - Our guard relay family has been under a sustained circuit-building DoS wave since 2026-06-25 23:00 UTC, still ongoing: open circuits at 20x peak and 8x sustained, onionskin load 7x, stream creation 12x -- but bandwidth only +20%. Millions of near-idle circuits. See the attached charts (fleet open circuits, onionskin processing, and bandwidth, Jun 10 - Jul 10). - Impact contained so far: tor's DoS defenses engaged, brief onionskin drops on a small subset of relays, consensus flags dipped ~5%, zero TCP port exhaustion and zero global rate-limit events.
<...>
Is anyone else seeing this since Jun 25? Happy to share more detail.
I run the non-exit relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3
I have seen weird circuit behavior since about July 1st. Number of circuits are much higher than normal, about 120k instead of 80k. Every 2 hours, on the hour, the number of circuits drops before quickly climbing back to the high level.
What do you mean by "tor's DoS defenses engaged"? The automatic ones or something of your own?
Seeing good success limiting memory growth by setting DosCircuitCreationBurst 20 instead of network default of 60 to handle the current idle circuit connection flow. DoSCircuitCreationBurst sets how many circuit-creation requests an incoming requestor may burst before Tor’s per-client DoS rate limiter begins rejecting excess requests. Setting DoSCircuitCreationBurst 20 cut RSS growth from 19.00 to 5.00 MiB/h and from 15.29 to 1.27 MiB/h—reductions of 74% and 92%. The RSS memory growth followed the setting: 15.25→0.50 MiB/h when lowered to 20, and 4.37→13.23 MiB/h when restored to 60. Live traffic remained strong, while CPU and consensus weight stayed similar among A/B relay test groups. See attached infographic for more details. On Wednesday, July 15th, 2026 at 6:51 AM, Tor at 1AEO via tor-relays <tor-relays@lists.torproject.org> wrote:
@Logforme — stock defenses, nothing custom: Tor's built-in DoS subsystem, driven by consensus parameters every relay applies by default (a source holding a second connection may create circuits at 2/sec with a burst of 60, and keep at most 50 concurrent connections per tor process). You can watch them fire in tor_relay_dos_total (via Tor MetricsPort). Your ~1.5x is consistent with the same flood — intensity varies hugely by position and weight, and our guard-only fleet sits at the extreme end. We haven't looked for a 2-hour periodicity; our circuits recede and resurge on a multi-day scale.
What's firmed up since my first mail:
* Three attacks offset in time, not one: an onion-service INTRODUCE2 flood (peaked Jun 27, then collapsed), the main circuit-creation flood (onionskins peaked Jun 29 at ~11.5x, ~97% ntor_v3; open circuits Jul 5 at ~20x), and since Jul 5 malformed, protocol-violating circuits — tor_relay_circ_proto_violation_total surged >150x, peaked Jul 6, still running at dozens of times baseline.
* Network-wide, in the public archives: relays signing overload-general climbed from a 2–3% baseline to 8.2% on Jun 28, then a second wave to 12.2% (1,254 relays) on Jul 12. It lands on guards: guard-only overload hit ~17.7% by Jul 12 while pure exits stayed far lower. Running-flag churn roughly tripled — ~5,900 distinct relays flapped Running at least twice vs ~2,000 in an equal pre-flood window: saturated relays failing reachability probes while still relaying, not going down.
* The cost to absorb it: busiest hosts pegged at 90–99% CPU for two weeks (raw ntor cost), resident memory ~2.5x fleet-wide (~8x on the worst relays) with kernel OOM kills on the hardest-hit hosts (every process auto-restarted), and real onionskin drops only on our smallest host (7.6% of its own load; zero everywhere else). Refinements to my first mail: onionskins settled at 6.3x avg / 11.5x peak, streams 2.5x avg / 6.0x peak (the early 7x/12x were point-in-time reads).
Full write-up in four posts — every number is an aggregate counter or reproducible from CollecTor/Onionoo:
* Network-wide picture, public data alone: https://1aeo.com/blog/tor-network-dos-wave-june-2026.html * Anatomy of the attack (the three waves): https://1aeo.com/blog/circuit-building-dos-anatomy-june-2026.html * What absorbing it costs an operator: https://1aeo.com/blog/circuit-building-dos-fleet-cost-june-2026.html * Measurement traps + what Tor could change: https://1aeo.com/blog/defending-against-circuit-dos-june-2026.html
Chart-reproduction scripts: https://github.com/1aeo/1aeo-blog-charts
Attached: the three waves in one picture, Tor's defenses firing per vector, and the network-wide overload curve. On Monday, July 13th, 2026 at 12:56 PM, Logforme via tor-relays <tor-relays@lists.torproject.org> wrote:
On 7/10/26 18:44, Tor at 1AEO via tor-relays wrote:
Summary: - Our guard relay family has been under a sustained circuit-building DoS wave since 2026-06-25 23:00 UTC, still ongoing: open circuits at 20x peak and 8x sustained, onionskin load 7x, stream creation 12x -- but bandwidth only +20%. Millions of near-idle circuits. See the attached charts (fleet open circuits, onionskin processing, and bandwidth, Jun 10 - Jul 10). - Impact contained so far: tor's DoS defenses engaged, brief onionskin drops on a small subset of relays, consensus flags dipped ~5%, zero TCP port exhaustion and zero global rate-limit events.
<...>
Is anyone else seeing this since Jun 25? Happy to share more detail.
I run the non-exit relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3
I have seen weird circuit behavior since about July 1st. Number of circuits are much higher than normal, about 120k instead of 80k. Every 2 hours, on the hour, the number of circuits drops before quickly climbing back to the high level.
What do you mean by "tor's DoS defenses engaged"? The automatic ones or something of your own?
Complementary to DosCircuitCreationBurst 20, leaving all the other default settings, seeing good success quickly reclaiming unused memory during the current idle connection circuit DoS with mimalloc allocator instead of default glibc on latest Ubuntu / Debian. They both peak to around same RSS memory growth, ~50GB per relay, under current DoS, but mimalloc releases fairly quickly for these idle circuits in the current flood, while glibc holds the memory until the process is terminated. See attached chart. Previously, we also saw benefits of reduced overall RSS memory growth and consumption using mimalloc vs other memory allocators on guard relays. Speculating a relation to heap fragmentation caused from directory cache serving. https://1aeo.com/blog/mimalloc-209-tor-relay-deployment.html On Wednesday, July 22nd, 2026 at 10:24 PM, Tor at 1AEO <tor@1aeo.com> wrote:
Seeing good success limiting memory growth by setting DosCircuitCreationBurst 20 instead of network default of 60 to handle the current idle circuit connection flow.
DoSCircuitCreationBurst sets how many circuit-creation requests an incoming requestor may burst before Tor’s per-client DoS rate limiter begins rejecting excess requests.
Setting DoSCircuitCreationBurst 20 cut RSS growth from 19.00 to 5.00 MiB/h and from 15.29 to 1.27 MiB/h—reductions of 74% and 92%.
The RSS memory growth followed the setting: 15.25→0.50 MiB/h when lowered to 20, and 4.37→13.23 MiB/h when restored to 60.
Live traffic remained strong, while CPU and consensus weight stayed similar among A/B relay test groups.
See attached infographic for more details.
On Wednesday, July 15th, 2026 at 6:51 AM, Tor at 1AEO via tor-relays <tor-relays@lists.torproject.org> wrote:
@Logforme — stock defenses, nothing custom: Tor's built-in DoS subsystem, driven by consensus parameters every relay applies by default (a source holding a second connection may create circuits at 2/sec with a burst of 60, and keep at most 50 concurrent connections per tor process). You can watch them fire in tor_relay_dos_total (via Tor MetricsPort). Your ~1.5x is consistent with the same flood — intensity varies hugely by position and weight, and our guard-only fleet sits at the extreme end. We haven't looked for a 2-hour periodicity; our circuits recede and resurge on a multi-day scale.
What's firmed up since my first mail:
* Three attacks offset in time, not one: an onion-service INTRODUCE2 flood (peaked Jun 27, then collapsed), the main circuit-creation flood (onionskins peaked Jun 29 at ~11.5x, ~97% ntor_v3; open circuits Jul 5 at ~20x), and since Jul 5 malformed, protocol-violating circuits — tor_relay_circ_proto_violation_total surged >150x, peaked Jul 6, still running at dozens of times baseline.
* Network-wide, in the public archives: relays signing overload-general climbed from a 2–3% baseline to 8.2% on Jun 28, then a second wave to 12.2% (1,254 relays) on Jul 12. It lands on guards: guard-only overload hit ~17.7% by Jul 12 while pure exits stayed far lower. Running-flag churn roughly tripled — ~5,900 distinct relays flapped Running at least twice vs ~2,000 in an equal pre-flood window: saturated relays failing reachability probes while still relaying, not going down.
* The cost to absorb it: busiest hosts pegged at 90–99% CPU for two weeks (raw ntor cost), resident memory ~2.5x fleet-wide (~8x on the worst relays) with kernel OOM kills on the hardest-hit hosts (every process auto-restarted), and real onionskin drops only on our smallest host (7.6% of its own load; zero everywhere else). Refinements to my first mail: onionskins settled at 6.3x avg / 11.5x peak, streams 2.5x avg / 6.0x peak (the early 7x/12x were point-in-time reads).
Full write-up in four posts — every number is an aggregate counter or reproducible from CollecTor/Onionoo:
* Network-wide picture, public data alone: https://1aeo.com/blog/tor-network-dos-wave-june-2026.html * Anatomy of the attack (the three waves): https://1aeo.com/blog/circuit-building-dos-anatomy-june-2026.html * What absorbing it costs an operator: https://1aeo.com/blog/circuit-building-dos-fleet-cost-june-2026.html * Measurement traps + what Tor could change: https://1aeo.com/blog/defending-against-circuit-dos-june-2026.html
Chart-reproduction scripts: https://github.com/1aeo/1aeo-blog-charts
Attached: the three waves in one picture, Tor's defenses firing per vector, and the network-wide overload curve. On Monday, July 13th, 2026 at 12:56 PM, Logforme via tor-relays <tor-relays@lists.torproject.org> wrote:
On 7/10/26 18:44, Tor at 1AEO via tor-relays wrote:
Summary: - Our guard relay family has been under a sustained circuit-building DoS wave since 2026-06-25 23:00 UTC, still ongoing: open circuits at 20x peak and 8x sustained, onionskin load 7x, stream creation 12x -- but bandwidth only +20%. Millions of near-idle circuits. See the attached charts (fleet open circuits, onionskin processing, and bandwidth, Jun 10 - Jul 10). - Impact contained so far: tor's DoS defenses engaged, brief onionskin drops on a small subset of relays, consensus flags dipped ~5%, zero TCP port exhaustion and zero global rate-limit events.
<...>
Is anyone else seeing this since Jun 25? Happy to share more detail.
I run the non-exit relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3
I have seen weird circuit behavior since about July 1st. Number of circuits are much higher than normal, about 120k instead of 80k. Every 2 hours, on the hour, the number of circuits drops before quickly climbing back to the high level.
What do you mean by "tor's DoS defenses engaged"? The automatic ones or something of your own?
On 23/07/2026 07:24, Tor at 1AEO via tor-relays wrote:
Seeing good success limiting memory growth by setting DosCircuitCreationBurst 20 instead of network default of 60 to handle the current idle circuit connection flow. But best is to not let them in.
I do block here connection attempts from 130 ipv6 /64 and 1500 IPv4 systems which are accountable for the majority of pain related to CPU, OOM and Tor DDoS/circuit protocol violations etc. -- Toralf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. I'm finding very good success automatically blocking an entire /24 (and /64 for IPv6) with a >8/m over 2m and 16/h over 1h. Obviously the list of Tor relays is whitelisted (kept up to date with the cached consensus file that's added to an nftables set). This substantially reduces the amount of malicious load on my relays compared to the original ruleset. I also drop established connections once they are blacklisted, otherwise I keep seeing the same Contabo and Hetzner IPs remaining connected and continue using a significant amount of resources. There seem to be no false positives as the chances that multiple people in the same /24 would be using me as their guard and all restarting Tor within the same few minutes is very low. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCambCOAAKCRAw+TRLM+X4 xtaxAQCGefZYBo3ixdwkf8iq4xVJw/MpVcSBW+6vcXXPd3xDzgEA7V0vFgo+8BCY mR3hK2f4oheOtdjYFFKR2RM1c1+14A0= =ZtJu -----END PGP SIGNATURE-----
Is there a list of those Ipv6 and Ipv4 addresses which you block that we could use? From: Toralf Förster via tor-relays <tor-relays@lists.torproject.org> Sent: 23 July 2026 12:00 To: tor-relays@lists.torproject.org Cc: Toralf Förster <toralf.foerster@gmx.de> Subject: [tor-relays] Re: Circuit-building DoS wave: 20x peak, 8x sustained circuits on guard relays since Jun 25 On 23/07/2026 07:24, Tor at 1AEO via tor-relays wrote: + But best is to not let them in. I do block here connection attempts from 130 ipv6 /64 and 1500 IPv4 systems which are accountable for the majority of pain related to CPU, OOM and Tor DDoS/circuit protocol violations etc. -- Toralf
On 27/07/2026 04:28, forest-relay-contact--- via tor-relays wrote:
There seem to be no false positives as the chances that multiple people in the same /24 would be using me as their guard and all restarting Tor within the same few minutes is very low. Blocking a /24 subnet blocks up to 253 victims (Tor clients, Tor bridges etc, somethg else) if 1 malicious user is able to place a relay there.
-- Toralf
On 27/07/2026 04:28, forest-relay-contact--- via tor-relays wrote:
Obviously the list of Tor relays is whitelisted (kept up to date with the cached consensus file that's added to an nftables set). Why to trust a Tor relay ip more than any other ip? How did this handle Tor bridges?
-- Toralf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Toralf Förster wrote:
Blocking a /24 subnet blocks up to 253 victims (Tor clients, Tor bridges etc, somethg else) if 1 malicious user is able to place a relay there.
That's possible but unlikely. I don't see it as much more of a risk than accidentally blocking a VPN or a Hetzner reseller (many Hetzner resellers give their clients an /80 even when Hetzner themselves serves a /64). It's not going to be easy for an attacker to get on the same /24. While in theory someone using Contabo with me as their guard might get blocked as collateral, surely the number of people who get _unblocked_ due to my relays no longer overloading will be greater. I have considered making each of my relays automatically share a list of their connections so that I could treat any non-relay IP that's making (say) one connection to 10 of my relays as malicious. I decided against that because it would share sensitive information among too many hosts. After all, if one of my relays (all of which are on diverse providers) gets compromised, I wouldn't want it to know who is using all my _other_ relays as guards. I might have them all send their list to a single VPS with AMD SEV-SNP and have that VPS tally the IPs and decide if they need to be blocked and then reply with only the selected IPs, but that's probably more work than is needed, since the current system is working well enough so far.
Why to trust a Tor relay ip more than any other ip?
Tor relays are more likely to get kicked off the network if they engage in a DDoS attack against other relays. I still limit the total number of simultaneous connections they can make, but I exempt them from the blacklist. After all, there's a legitimate reason why one Tor IP might make 8 connection attempts in rapid succession (a reboot with 8 relays), but there's no legitimate reason a client would.
How did this handle Tor bridges?
I considered using that one asshat's public Tor bridge list but decided against it since I'd have to trust a 3rd party list (whereas the relay list is parsed directly from Tor's cached consensus). I figure that the chance that more than 8 bridges on the same /24 will make a new connection to me within a 2 minute period is very low. I did consider the possibility of more than 16 per hour so I might raise that limit. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCamgEWAAKCRAw+TRLM+X4 xsweAP0eXjaiJUXBDT3CVH424kSFJJpwNmuRpxPxMYeR7RTf0wD+IOKH5VxxS7EI /yVcdIc3Lf3qxqTHRF7q6K3m9qIlXg8= =LyvJ -----END PGP SIGNATURE-----
On 28/07/2026 03:22, forest-relay-contact--- via tor-relays wrote:
I figure that the chance that more than 8 bridges on the same /24 will make a new connection to me within a 2 minute period is very low. Some estimation and more considerations were made in [1] and [2]
[1] https://gitlab.torproject.org/tpo/core/tor/-/work_items/40636 [2] https://gitlab.torproject.org/tpo/community/support/-/work_items/40093 -- Toralf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Toralf Förster wrote:
Some estimation and more considerations were made in [1] and [2]
That's interesting. I suppose I could just disable the limits for other relays and only keep the limits for non-relays. It'll be as simple as removing "add @tor_connlimit4 { ip saddr ct count over 16 } drop" from my nftables ruleset. I'm waiting for the DDoS attack to subside so I can make sure there are no false positives being caught. I wonder who is behind them and why. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCamhh9wAKCRAw+TRLM+X4 xieMAP9Un2Fg033SvT2rWAiXy3A6w4lWji8ZOT8rxxkVr8Qc2QEAw3duUork6fot SC5e2WepEMLjJ1okyATqYPJN1HBY4QY= =DjcY -----END PGP SIGNATURE-----
participants (5)
-
forest-relay-contact＠cryptolab.net -
gerard＠bulger.co.uk -
Logforme -
Tor at 1AEO -
Toralf Förster