Anubis bypass shows bot proof-of-work mostly catches low-effort scrapers

Why it matters

Proof-of-work can cheaply shed basic crawler traffic, yet programmable agents can automate the challenge and shift the recurring cost to human visitors.

Xe Iaso's Anubis bot wall met a purpose-built bypass on July 9, when systems engineer Farid Zakaria published a critique of the proof-of-work software and released a command-line client that automates its challenge.

The bypass sharpens a limitation Iaso has already acknowledged: Anubis works best against low-effort crawlers that cannot execute JavaScript. A determined operator can add a solver, store the resulting authorization cookie and continue scraping. The same adaptation is increasingly within reach of an AI coding agent.

Iaso created Anubis after a scraper hammered a personal Git server. In a January interview, Iaso described assembling the first version during "an afternoon of rage" after a Kubernetes configuration mistake placed high-traffic services on rotational storage. The side project became a widely adopted, self-hosted defense for open-source infrastructure, with 20.9k GitHub stars when crawled.

Anubis gives those operators a way to reduce crawler load without moving their sites behind a managed service such as Cloudflare. Zakaria's bypass shows the boundary of that bargain: proof-of-work raises the cost of the first request, while software can spread that cost across every request that follows.

A kernel patch led to a bot-wall bypass

Zakaria encountered Anubis while using an LLM to read a Linux kernel mailing-list thread. He was working on a patch involving $ORIGIN support for ELF interpreters through BPF and binfmt_misc, work closely connected to his research into binary loading and software dependencies.

Zakaria, who lists Meta as his current employer, completed a computer science PhD at UC Santa Cruz in June 2025. His dissertation examined fast startup, binary introspection and explicit dependency control. The Anubis challenge interrupted a technically ordinary workflow for him: giving a coding model the primary discussion behind a kernel change.

The result was anubis-fetch, a small Go utility that retrieves pages protected by Anubis and some Cloudflare checks. The repository had one commit and 26 stars when crawled, so it remains a demonstration rather than an established scraping package. Its implementation still makes the central point plainly.

The client first looks for a previously saved Anubis authorization cookie. Without one, it uses the req Go HTTP client to imitate Chrome's TLS and HTTP/2 fingerprint, extracts the challenge and searches for a valid SHA-256 nonce. If that path fails, it launches headless Chromium and runs the site's JavaScript.

Zakaria's repository reports about 0.6 seconds for its in-process path and roughly two seconds for the browser fallback. Those figures come from the project's own documentation and have not been independently benchmarked. The mechanics are visible in the source: cookie persistence, challenge solving and a general-purpose browser fallback are all implemented.

That sequence matters because a scraper pays the proof-of-work cost once for each cookie's usable life. Human visitors can encounter the spinner again when cookies expire, disappear or fail to carry across devices and browsing modes. Automation can preserve the credential deliberately.

Anubis was built to deter a cheaper class of crawler

Zakaria writes that "the exact adversary Anubis targets defeats it trivially." Iaso's description of the target is narrower. In the January interview, Iaso said Anubis is "mostly doing rate limiting" and that even a simple barrier confuses many low-effort scrapers into giving up. Those crawlers often do not execute JavaScript, leaving them stranded on the challenge page.

That makes anubis-fetch a boundary test rather than a universal defeat. It demonstrates that a motivated client can pass the wall. Anubis can still protect a server when most unwanted traffic comes from generic crawlers whose operators have no reason to build a site-specific adapter.

The project's own documentation is unusually direct about the cost. The Anubis README calls the software "a bit of a nuclear response," warns that it may block smaller scrapers and services such as the Internet Archive, and tells operators that Cloudflare will be sufficient in many cases. Anubis exists for administrators who cannot or will not make that trade with a managed edge provider.

Iaso has also moved Anubis beyond a single static proof-of-work page. The project's releases added weighted request rules, lighter challenge methods, browser-specific fixes, IP blocklists and tools for feeding suspicious crawlers poisoned content. The release history reflects a project trying to classify traffic before forcing every visitor through the same expensive path.

That work carries its own maintenance burden. Iaso said in the January interview that Anubis remained a nights-and-weekends project despite needing the attention of a full-time job. Anubis grew because small-site operators needed immediate relief from crawler traffic, leaving its creator responsible for browser quirks, accessibility failures and adversaries who can change behavior faster than a volunteer project can ship.

The recurring cost lands on people

Zakaria's strongest criticism concerns visitors who cannot complete the JavaScript challenge reliably. He points to text browsers, RSS clients, mobile devices and accessibility-sensitive software, and argues that clients that do not run JavaScript are left out.

Zakaria modeled the accumulated cost using a two-second wait and 20 joules of device energy for each solve. Under those assumptions, one million challenges per day would consume about 23 person-years of visitor time annually. Ten million would consume about 230 person-years.

Those totals are scenarios, not measurements. Zakaria does not establish how many Anubis challenges run globally each day, and the energy estimate varies with hardware, browser behavior and challenge configuration. His comparison of raw work is more concrete: a difficulty-four challenge requires an expected 65,536 hashes, which he estimates at about 1.3 milliseconds in native Go and 130 milliseconds in browser JavaScript before page loading, worker startup and redirects.

The asymmetry will shape the next generation of bot defenses. Proof-of-work remains attractive because it is cheap to verify, self-hostable and effective against basic crawlers. Coding agents make adapters such as anubis-fetch cheaper to create, while headless browsers provide a fallback for challenges that cannot be reproduced directly.

Anubis still buys overloaded sites time. Zakaria's tool establishes what that time is worth and who keeps paying for it. A challenge can shed unsophisticated traffic immediately. Sustained defense requires identity, behavior and rate controls that make each automated request expensive, instead of repeatedly charging the humans trying to read the page.