Alleged DDoS by archive.today: The February 2026 Incident Explained

Step-by-step technical analysis, simulation, timeline and source documentation. All contested claims are presented as reported and attributed to the public sources listed below.

Executive summary

What was reported

In early February 2026 a first-person investigation documented that archive.today’s CAPTCHA page included a short client-side JavaScript loop causing visitors’ browsers to repeatedly request a target site’s search endpoint every ~300 milliseconds. This made the browsers act as distributed request generators against the target. :contentReference[oaicite:0]{index=0}

Summary of sources: the investigator’s post includes code screenshots, a timeline and redacted correspondence; community threads on Hacker News and Reddit discussed and validated aspects of the behavior. :contentReference[oaicite:1]{index=1}

Simulation of Repeated Request Attack (safe)

This is a visual-only simulation — it does not perform network requests. It demonstrates the resource-amplifying pattern when many browsers run the same short-interval loop.

Interval 300 ms

Requests/sec

0.00

Total requests

0

[Simulation log — simulated GET lines shown; no requests are sent]

Step 1 — Page loads

The CAPTCHA page includes a small script. The investigator captured the code in the page source. :contentReference[oaicite:2]{index=2}

Step 2 — Timer starts

The timer uses a short interval (reported ≈ 300ms). Each tick calls a request builder. :contentReference[oaicite:3]{index=3}

Step 3 — Randomized queries

Each request includes a randomized query string to avoid caching, forcing the server to perform work per request. :contentReference[oaicite:4]{index=4}

Step 4 — Aggregate effect

When many users run the loop, aggregate requests grow linearly with concurrent open pages — a large-scale resource pressure event results. :contentReference[oaicite:5]{index=5}

Technical explanation (concise)

The reported pattern is simple but dangerous: every 300ms the page constructs a URL (target + random token) and issues a request. Because the token differs each time, caches are bypassed and the origin must compute or serve each response. That increases CPU, DB and bandwidth use on the target. :contentReference[oaicite:6]{index=6}

Practical mitigation

• Rate-limit / 429 throttles for high-frequency clients.
• Ignore or serve cheap cached responses for obviously random short queries.
• CDN/WAF rules to drop repeated patterns and block abusive referrers.
• Log collection: capture timestamps, user-agent, and referrer for abuse reports.

Timeline & community response

The investigator’s timeline includes initial publication of an OSINT post (2023), later correspondence and the discovery of the code on archive.today’s CAPTCHA page (January–February 2026). Community threads on Hacker News and Reddit examined the code, screenshots, and discussed impact and remediation. :contentReference[oaicite:7]{index=7}

Sources

• Gyrovague — first-person investigation (code, screenshots, correspondence). :contentReference[oaicite:8]{index=8}
• Hacker News — community discussion. :contentReference[oaicite:9]{index=9}
• Reddit /r/DataHoarder — thread and comments. :contentReference[oaicite:10]{index=10}