Anubis Proof of Work Bypass: What Solving Really Costs

Commercial bot management asks a question about identity. It collects TLS handshakes, JavaScript artefacts, timing, canvas output, and resolves all of it to a verdict about whether you are a browser driven by a person. You cannot read the rules, so you probe them. Anubis asks a different question: will you spend CPU time to continue? There is no secret to recover. The rule is published, the cost is adjustable by the operator, and the verification is deliberately one-sided.

The asymmetry is the whole mechanism. The project's design note puts it this way:

The server then only has to do one sha256 operation: the one that confirms that the challenge (generated from request metadata) and the nonce (provided by the client) match the difficulty number of leading zeroes.

One hash to check, tens of thousands to produce. The lineage is Hashcash, and the design doc names it: a tax that a person browsing a few pages never notices and an industrial crawler cannot ignore.

That reframes the question you are actually asking. With a fingerprinting vendor, the question is "can I look real enough". Here it is arithmetic: how many gated pages, at what difficulty, on what hardware, and is that cheaper than asking for an API. For the fingerprint-realism problem you can read our notes on Cloudflare Turnstile and Kasada, both of which also use proof of work but bury it under code you are not allowed to read. Anubis is the opposite case, and it is worth treating as its own category rather than one more interstitial to get past. The general prevention playbook in our guide to avoiding CAPTCHAs mostly does not apply, because nothing you do to your headers makes a hash cheaper.

One honest caveat from the project itself, worth reading before you build anything permanent on top of the current mechanism:

Ultimately, this is a hack whose real purpose is to give a "good enough" placeholder solution so that more time can be spent on fingerprinting and identifying headless browsers (EG via how they do font rendering) so that the challenge proof of work page doesn't need to be presented to known legitimate users.

The authors describe proof of work as a placeholder on the way to fingerprinting. Build accordingly.

Anubis is published by Techaro at github.com/TecharoHQ/anubis under the MIT licence, written in Go, with the newer proof-of-work cores in Rust compiled to WebAssembly. The repository describes itself as a tool that "Weighs the soul of incoming HTTP requests to stop AI crawlers", and the project site titles it a "Web AI Firewall Utility".

Everything below was read on 9 October 2026 from the GitHub API and from raw files at tag v1.28.1:

So: not abandoned by any reading. The newest release carries the same date as the figures above, main had a commit that morning, and five tags landed between 30 August and 9 October 2026. That matters for a scraping decision, because the mechanism is still moving, and a solver written against the 2025 behaviour is already wrong in the way described in the next two sections.

Techaro also sells a proprietary build called BotStopper, which is where the harder challenge methods and the headless-browser detector live. The open-source project and the commercial one share a codebase and a policy format, so an Anubis deployment you meet may have capabilities the public repo does not document fully. No price is quoted here because none was verified.

The single most expensive mistake is detecting this gate by status code. Anubis ships with this in its default configuration file, comment included:

# By default, send HTTP 200 back to clients that either get issued a challenge
# or a denial. This seems weird, but this is load-bearing due to the fact that
# the most aggressive scraper bots seem to really, really, want an HTTP 200 and
# will stop sending requests once they get it.
status_codes:
  CHALLENGE: 200
  DENY: 200

A challenge is a 200. A denial is a 200. Any pipeline that treats 200 as success will happily store interstitials for weeks. Two live checks on 9 October 2026 confirm it in production: https://anubis.techaro.lol/ (the project's own docs site) answered HTTP/1.1 200 OK with a challenge page, and https://bugs.freebsd.org/ answered HTTP/1.1 200 OK with a challenge page from Anubis 1.26.2. Our note on detecting when your scraper is blocked covers the general principle; Anubis is the sharpest example of it.

What does identify the gate, reliably, is the page body. The challenge template embeds its state as JSON script tags and loads its assets from a fixed path prefix: