Back to Blog

Proof-of-Work Walls Arrive on Regular Websites: CrowdSec 1.8, Anubis, and Why Hashing Isn't the Main Issue

On September 1, 2026, CrowdSec released version 1.8: proof-of-work and browser fingerprinting are now available in the self-hosted WAF. Let's analyze why the detection recognized the uselessness of resident IP and clean TLS, how much the PoW task costs for a human and a bot (0.017 seconds with the native solver versus 2 minutes on a phone), and why the commercial PoW from Kasada is fundamentally more dangerous than the open Anubis.

📅September 4, 2026
Proof-of-Work Walls Arrive on Regular Websites: CrowdSec 1.8, Anubis, and Why Hashing Isn't the Main Issue

On September 1, 2026, CrowdSec 1.8 was released — and in the open-source WAF that can be installed on your server with a single helm install, two things arrived at once: browser fingerprinting and proof-of-work. Until now, PoW walls have mainly been encountered in git forges and mailing list archives. Now, such a layer could appear on any site with five hundred visitors per day.

Let's explore what exactly has changed, why detection has shifted towards "paying with CPU," and — most importantly — why the hash in this setup is the least of the problems.

What Happened: PoW Descended from Git Forges to Regular Websites

CrowdSec is a self-hosted system: the agent reads logs, the WAF stands in front of the application, and the "bouncers" block requests. In the 1.8 release, the team added a mechanism to the WAF that answers not the question "is this IP bad?" but rather "is this even a browser with a human or a bot pretending to be one?" The answer is gathered from the fingerprint (browser characteristics and TLS signature) and proof-of-work — a computational task that the client must solve before the backend sees the request.

The authors state their motivation bluntly: the average bot of 2026 arrives with a real Chrome browser, a consistent TLS fingerprint, a residential IP — and it has more patience than a duty engineer. This acknowledgment from detection is worth more than any analytics: the residential address and neat TLS have ceased to be distinguishing features. Since a bot no longer differs from a human based on IP reputation and handshake, protection seeks a sign that is cheap for the browser and expensive for the machine park.

At the same time, POWBlock emerged on Hacker News around the same days — "a proof-of-work microservice for any server." One release could be dismissed as coincidence, but two independent signals in a week indicate a trend.

How the PoW Wall Works: An Example of Anubis

The benchmark of the genre is Anubis: a reverse proxy written in Go under the MIT license, developed by Xe Iaso under the Techaro brand since January 2025. The idea comes straight from Adam Back's 1997 hashcash: the client iterates through values until SHA-256 produces a hash with the required number of leading zeros. If solved, the client receives a signed JWT cookie (techaro.lol-anubis-auth) and temporary access. If not solved, the backend will not know about you.

The difficulty is set by the administrator. By default, Anubis challenges everything that resembles a browser — that is, anything with the string Mozilla in the User-Agent. The measurements show what each level costs:

  • Difficulty 1 — less than 100 ms.
  • Difficulty 4 (default) — about 1.35 seconds on an Intel Core Ultra 7 165H, which is approximately 87,600 hashes per second in the browser.
  • Difficulty 8 — about 11 seconds.
  • Difficulty 10 — about 114 seconds.

The difference between the fourth and tenth levels is roughly 84 times. The list of adopters looks impressive: the Linux kernel mailing list archive and the kernel git server, sourcehut, FFmpeg, GitLab for the GNOME project, Wine, sourceware.org, FreeCAD, ScummVM, Enlightenment, UNESCO. At Duke University, a pilot in June 2025 filtered out more than 4 million unwanted HTTP requests per day — about 90% of junk traffic — and only 12 people complained about issues in a week.

These walls did not appear out of malice. At Read the Docs, a single crawler downloaded 73 TB in a month; after blocking, daily traffic dropped from 800 GB to 200 GB, saving about $1,500 per month. Drew DeVolt described how the fight against crawlers consumed between 20% and 100% of certain weeks. Against the backdrop of a 23.51% increase in automated traffic in 2025 and nearly tripling of AI traffic within the year, administrators began to adopt what works quickly.

The Twist: PoW Almost Doesn't Work Against Industrial Parsing

And now for the uncomfortable part, which is rarely mentioned in press releases. Proof-of-work relies on the asymmetry of "cheap to verify, expensive to solve." In the web, this asymmetry is skewed the other way.

A legitimate visitor considers hashes to be slow JavaScript in the browser. Those who come for data consider them to be native code. Tavis Ormandy wrote a solver in 25 lines of C: a task of difficulty 5 is solved in about 0.017 seconds — that's roughly 200 times faster than the browser's SubtleCrypto. The gap is even greater on a GPU, around a hundred times or more. The arithmetic is simple: for a large vendor, bypassing all Anubis sites costs almost nothing.

This is not theory. Codeberg reported back in August 2025 that many scraper bots learned to solve Anubis challenges. The wall did not become useless — for several months it filtered out the majority — but as a barrier for someone willing to invest one evening in a native solver, it does not hold.

As usual, the bill is paid by the live user. Difficulty 5 takes about 2 seconds on a new MacBook, tens of seconds on an old laptop, and up to two minutes on a phone. On GitLab GNOME, they recorded a case of a half-hour freeze in Firefox — an outlier, but indicative. Plus, there are strict exceptions: by default, Anubis requires JavaScript, so RSS readers, curl, wget, and Lynx simply fail. The project is addressing this — in version 1.20.0, a path without JS via meta-refresh was introduced — but in 1.22.0, Proof of React arrived, which, on the contrary, raised the browser requirements.

It's also worth noting the stability of the project itself: about half of the code is committed by one person, and among 80+ contributors, only one other developer has surpassed ten commits. Additionally, Anubis integrates a paid service, Thoth, for GeoIP and BGP filtering — meaning the open-source project has a commercial neighbor.

Where PoW Really Bites: The Commercial Version Works Differently

Here lies the main substitution of concepts. Kasada, hCaptcha, and Cloudflare Turnstile also use proof-of-work — but not in the same way as Anubis.

In Anubis, the puzzle is the wall: execute JS, calculate the hash — you pass. One signal, one barrier. In commercial systems, PoW works as attestation. In Kasada, the task takes a couple of milliseconds — so little that as a barrier, it is meaningless. The point is different: to solve it, the client must run an obfuscated virtual machine, within which the actual detection occurs. If you calculate the hash without executing everything else, you get nothing. hCaptcha layers PoW on top of image verdicts, increasing the computational cost for suspicious clients, while Turnstile considers PoW as one signal among many environmental probes.

The difference is fundamental. The open wall can be broken by a cheap native solver. The commercial one is broken not by the hash, but by the necessity to honestly execute someone else's obfuscated code and not get caught in the environment — and this is expensive because obfuscation is regularly rotated. CrowdSec 1.8 is interesting precisely because it brings a hybrid of this logic (fingerprint alongside PoW) into the self-hosted world, where previously there was only a rate limit by IP.

What This Changes in Practice

If you are collecting data legally — monitoring prices, tracking your brand, conducting research — the conclusions are quite specific.

  1. The problem is not with the hash, but with the browser layer. The hash is calculated natively in milliseconds. The fingerprint, obfuscated VM, and correct environment are not. The practical shift: where an HTTP client was previously sufficient, now a real browser engine is needed. This is more expensive in terms of CPU and memory, and planning must be done accordingly.
  2. The economics are shifting from traffic to time and CPU. Previously, the cost was calculated in IPs and gigabytes. Now, seconds per page and core load are added to it. It is necessary to measure not the price per gigabyte, but the cost of one successful record — with a PoW wall, these two metrics diverge especially significantly.
  3. A session becomes an asset. Anubis issues a JWT cookie for a limited time. If you change your IP after each request, you pay the PoW tax anew on each page. Sticky sessions on residential proxies provide a gain not in "anonymity," but directly in computations: one solution amortizes across dozens of pages. Aggressive rotation in the world of PoW turns from good practice into overspending.
  4. A solver does not replace behavior. The same logic applies as to why solvers for captchas have stopped solving the issue: you solve a visible task, while the verdict is made based on invisible signals surrounding it.
  5. Reduce frequency — it's cheaper than any wall. The PoW wave grew from stories like 73 TB in a month from a single crawler. Caching, conditional requests, a reasonable interval, and respect for robots.txt can take you off the radar before the challenge kicks in. Cheap data center addresses plus headless at maximum frequency — this is exactly the profile for which walls are set up.

Conclusion

CrowdSec 1.8 is not the "end of scraping," and Anubis has not become that either: a native solver closes a difficulty 5 task in 0.017 seconds, while a live person on an old phone waits up to two minutes. The real news is different. First, detection has openly acknowledged that a residential IP and clean TLS no longer prove anything. Second, the layer "prove that you are a browser" has ceased to be a privilege of large platforms with budgets for Kasada and has moved into open-source, which can be installed on regular websites.

One should prepare not for a battle with hashes, but for the realization that the cheap scheme of "many IPs plus a fast HTTP client" will fall away on increasingly smaller targets. The winning configuration is the opposite: fewer requests, a real browser, long sessions, and quality addresses where one reliable pass is needed, not a thousand cheap attempts.