A Year Under Flood: Ten Reported Episodes and July’s Memory Pressure

By 1AEO Team • Published July 16, 2026 • Updated July 29, 2026 • Thirteen months of flood telemetry: 1AEO fleet DoS counters through July 28 + Tor's public CollecTor archives through July 27, 2026

Correction, July 29, 2026. This post originally said 1AEO's overload stayed near zero through every episode, and that the network's worst day was July 12. The July 19–24 outbound directory-traffic surge coincided with memory pressure; the July review identified 135 distinct 1AEO relays that reported overload. July 21 had the highest daily report count in the June–July archive.

Updated October 20, 2026: the historical charts below have been rebuilt with explicit units and coverage. Our July chronology grouped ten episodes since September 2025, clustered in autumn 2025 and summer 2026 with smaller winter and spring periods. These are reported periods of elevated signals, not proof of two coordinated campaigns or a common attacker. The fleet record here ends July 28; this is not an October traffic update.

Ten Reported Episodes #

The abrupt September 4–6, 2025 increase remains clear in the historical counters. The recalculated circuit-creation rejection rate peaked at approximately 1.62 billion events per day on September 5. Elevated periods then recur through autumn, winter and spring. The July chronology also tracked onion-service introduction rejections, protocol-violation counters from late March, and the outbound directory-traffic surge of July 19–24. These signals describe different work and defense actions; rejection rates alone do not count all attempted or accepted work. We have removed the 125x quiet-baseline comparison because its original baseline windows have not been recovered.

Recomputed daily circuit-creation and introduction-request rejection rates from July 2025 through July 28, 2026, shown as estimated events per day on a logarithmic scale. September 5 circuit rejections peak near 1.62 billion per day. A lower panel shows eligible counter-series and native-target counts. Days with insufficient coverage are gaps rather than zeros; no quiet-baseline normalization is used.

What the Network Saw #

In the finalized June–July server-descriptor archives, 1,330 of 10,334 daily publishers (12.87%) included overload-general on July 21. By July 27 the count was 721 of 10,227 (7.05%). These are daily unions of publishing relays, not an instantaneous percentage of the consensus or an outage count. An overload report can persist across days. The replacement chart is limited to the June–July data rechecked here; it does not re-establish the old year-wide peak ranking.

Two-panel June-July 2026 public-data chart. Daily distinct server-descriptor publishers with overload-general peak at 1,330 on July 21. Official Tor Metrics outbound directory traffic for mirrors and authorities peaks at 70.429 Gbit/s on July 22, about 760.6 decimal TB/day. Missing directory-data dates remain gaps. Neither series measures unique attacks or user outages.

The July Directory Surge and Memory Pressure #

The July 19–24 period included a sharp rise in outbound directory traffic. The official Tor Metrics series gives 70.429 Gbit/s on July 22 for directory mirrors and authorities combined — approximately 760.6 decimal TB/day. This replaces the earlier 808.5 TB/day and 4.4x-baseline claims. Here, “write” means bytes sent, not descriptor uploads. The aggregate includes directory traffic beyond onion-service descriptors and does not establish deliberate slow-reading clients.

The July 29 review identified two fleet memory-pressure periods: July 23, 19:00–22:00 UTC and July 27, around 08:00 UTC. It reported 135 distinct relays, about 13% of the fleet, publishing overload reports at least once. Daily CollecTor counts and sub-daily Onionoo snapshots are different measures; the earlier wording incorrectly called a 92-relay snapshot the “true high” beside a 94-relay daily count. The July 27 event came after the directory surge; what re-triggered the memory pressure is not established. The planned July 28 service restart cleared in-memory overload state, so later counts cannot establish that the pressure had ended.

Tor's MaxMemInQueues handler accounted for approximately 221 GB removed on July 23, 117 GB on July 27, and 475 GB over July 23–28. These are managed-object byte counters, not a measurement of physical RAM returned to the operating system or proof that every byte was an outbound cell. Memory pressure can cause an overload-general report without a relay disappearing from the consensus. Neither a continuing consensus listing nor a flat reclaimed-byte counter establishes uninterrupted service or that the handler stopped being invoked.

Why Rejection Rate Does Not Measure Memory Cost #

Autumn 2025 had higher circuit-rejection rates in the available telemetry, but rejection counts do not reveal accepted work, retained circuits or memory use. Summer 2026 also brought substantial memory pressure. Journal-derived counters recorded 31 Tor-process OOM kills by July 13, separately from Tor's application-managed memory removals. That supports distinguishing kernel process kills from Tor's own cleanup. It does not establish that earlier episodes had zero memory impact, that all retained circuits were idle or malicious, or that this was the year's smallest attack.

Where It Stands, July 29 #

By the end of the measured window, introduction-request rejections had fallen from approximately 71.90 million events/day on July 25 to 4.88 million/day on July 28. Circuit-creation rejection rates remained elevated at approximately 35.63 million/day on July 27 and 38.74 million/day on July 28. The literal metric label introduce2_rejected records introduction requests rejected before forwarding; an introduction point receives INTRODUCE1 and forwards accepted requests toward the service as INTRODUCE2. These defense counters do not establish which attack modes remained, whether other work continued, or a shared controller.

How We Measured #

Fleet-side: we re-queried native tor_relay_dos_total series for July 1, 2025 through July 28, 2026. We calculate rate(counter[1d]) per original series before summing, at UTC day-end boundaries, and multiply by 86,400 for estimated events/day. Each included series needs at least 360 samples that day. Days below 90% of the larger of the target count or the preceding 31-day maximum reporting count are gaps; missing activity is not replaced with zero. The reporting set changes, so these totals are not directly comparable per-relay exposure or a complete attack census.

Network-side: the updated chart uses finalized June–July CollecTor server-descriptor archives, deduplicated per relay per publication day, and the official Tor Metrics directory-byte aggregate. Missing directory-data dates remain gaps. The original July 29 fleet-event summary is retained where identified, including the 135 distinct reporters and the unresolved July 27 trigger. A flat byte-removal series around 03:00 UTC on July 28 does not prove the handler stopped firing; the planned restart later that morning also resets relevant state. Aggregate counters only — no individual source-address records.

Related reading — this post is the year-long frame around our five-part series on the summer 2026 DoS period:  1. The Tor Network’s Circuit-Building DoS Wave in June–July 2026 — the network-wide view.  2. Anatomy of the Attack — the waves and vectors.  3. What It Actually Costs — the CPU and memory bill.  4. The Flood Below Tor — TCP listener pressure beneath Tor.  5. Defending Against Circuit-Building DoS — the fixes we're asking for.

Join the Mission