Summary: Multiple reports indicate that archive.today’s CAPTCHA page included client-side JavaScript that repeatedly issued requests to third-party sites’ search endpoints, creating DDoS-like traffic while the CAPTCHA page remained open. This post summarizes the timeline, community reaction, technical details, and short mitigation steps.

According to the original report, the CAPTCHA page runs a short `setInterval` loop that calls a site’s search endpoint with a randomized query string roughly every 300 milliseconds — ensuring responses are not cached and keeping the requests active while the CAPTCHA remains open. The code sample was published in the original write-up for verification.

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

Source material includes the original blog post with screenshots, the Hacker News discussion thread, and the Reddit community thread. See the links at the bottom.

Timeline & community reaction

Reporters and the site owner documented the behavior, the exchange of emails with the archive’s webmaster, and a GDPR complaint sent to the blog’s host — all of which are covered in the original article. The incident was also discussed on Hacker News and Reddit as users validated and debated the observations and implications.

Why this matters

Whether intentional or the result of a misconfiguration, a client-side pattern that turns visitors into request-generators can unintentionally weaponize normal traffic against third-party sites. This blurs lines between archival tooling, anti-abuse measures, and hostile traffic generation — with consequences for small sites running on limited resources.

Mitigation & immediate steps (quick)

• Rate-limit search endpoints and high-cost routes (e.g., return 429 or temporary 503 for excessive requests).
• Use WAF rules or CDN rate limiting to block repeated requests from the CAPTCHA page's referrers or abnormal request patterns.
• Add rules that ignore queries with obviously random strings for search endpoints, or serve lightweight cached responses for unknown queries.
• Consider listing offending domains in DNS/hosts filters (some blocklists already caught this behavior and prevented requests for users with blockers enabled).
• Log the request patterns and collect sample request headers and timestamps for abuse reports or forensics.

Attribution & sources

This post summarizes reporting and community discussion. Full technical details, screenshots, email timelines, and the code sample are in the original report and threads linked below.