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
participants (3)
-
Logforme -
Tor at 1AEO -
Toralf Förster