La evasión de Anubis muestra que la prueba de trabajo para bots atrapa mayormente a raspadores de bajo esfuerzo

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.

El muro para bots Anubis de Xe Iaso se encontró con un bypass diseñado específicamente el 9 de julio, cuando el ingeniero de sistemas Farid Zakaria publicó una crítica del software de prueba de trabajo y lanzó un cliente de línea de comandos que automatiza su desafío.

El bypass agudiza una limitación que Iaso ya ha reconocido: Anubis funciona mejor contra rastreadores de bajo esfuerzo que no pueden ejecutar JavaScript. Un operador determinado puede añadir un solucionador, almacenar la cookie de autorización resultante y continuar raspando. La misma adaptación está cada vez más al alcance de un agente de codificación impulsado por IA.

Iaso creó Anubis después de que un scraper atacara un servidor Git personal. En una entrevista de enero, Iaso describió haber ensamblado la primera versión durante "una tarde de ira" después de que un error de configuración de Kubernetes colocara servicios de alto tráfico en almacenamiento rotacional. El proyecto paralelo se convirtió en una defensa autoalojada ampliamente adoptada para infraestructura de código abierto, con 20.9k estrellas en GitHub cuando se rastreó.

Anubis ofrece a esos operadores una manera de reducir la carga de rastreadores sin mover sus sitios detrás de un servicio gestionado como Cloudflare. El bypass de Zakaria muestra el límite de esa transacción: la prueba de trabajo aumenta el costo de la primera petición, mientras que el software puede repartir ese costo entre todas las peticiones que sigan.

Un parche del kernel condujo a un bypass del muro para bots

Zakaria se topó con Anubis mientras usaba un LLM para leer un hilo de la lista de correo del kernel de Linux. Estaba trabajando en un parche relacionado con soporte de $ORIGIN para intérpretes ELF mediante BPF y binfmt_misc, un trabajo estrechamente conectado con su investigación sobre carga binaria y dependencias de software.

Zakaria, quien lista a Meta como su empleador actual, completó un doctorado en ciencias de la computación en UC Santa Cruz en junio de 2025. Su disertación examinó el arranque rápido, la introspección binaria y el control explícito de dependencias. El desafío de Anubis interrumpió un flujo de trabajo técnicamente ordinario para él: darle a un modelo de codificación la discusión principal detrás de un cambio del kernel.

El resultado fue anubis-fetch, una pequeña utilidad en Go que recupera páginas protegidas por Anubis y algunas comprobaciones de Cloudflare. El repositorio tenía un commit y 26 estrellas cuando se rastreó, por lo que sigue siendo una demostración en lugar de un paquete de scraping establecido. Su implementación aún deja el punto central en claro.

El cliente primero busca una cookie de autorización de Anubis guardada previamente. Sin una, utiliza el cliente HTTP de Go req para imitar la huella TLS y HTTP/2 de Chrome, extrae el desafío y busca un nonce SHA-256 válido. Si ese camino falla, lanza Chromium en modo headless y ejecuta el JavaScript del sitio.

El repositorio de Zakaria reporta alrededor de 0.6 segundos para su ruta en proceso y aproximadamente dos segundos para la alternativa con navegador. Esas cifras provienen de la propia documentación del proyecto y no han sido benchmarkeadas de forma independiente. La mecánica es visible en el código fuente: persistencia de cookies, resolución del desafío y un respaldo con navegador de uso general están todos implementados.

Esa secuencia importa porque un scraper paga el costo de la prueba de trabajo una sola vez por cada vida útil utilizable de la cookie. Los visitantes humanos pueden encontrar la animación de carga de nuevo cuando las cookies expiran, desaparecen o no se transfieren entre dispositivos y modos de navegación. La automatización puede preservar la credencial deliberadamente.

Anubis fue creado para disuadir a una clase de rastreadores más barata

Zakaria escribe que "el adversario exacto al que Anubis apunta lo derrota trivialmente." La descripción del objetivo por parte de Iaso es más estrecha. En la entrevista de enero, Iaso dijo que Anubis "está mayormente haciendo rate limiting" y que incluso una barrera simple confunde a muchos scrapers de bajo esfuerzo hasta que abandonan. Esos rastreadores a menudo no ejecutan JavaScript, dejándolos varados en la página del desafío.

Eso hace de anubis-fetch una prueba de límite en lugar de una derrota universal. Demuestra que un cliente motivado puede pasar el muro. Anubis todavía puede proteger un servidor cuando la mayor parte del tráfico no deseado proviene de rastreadores genéricos cuyos operadores no tienen razones para construir un adaptador específico para el sitio.

La propia documentación del proyecto es inusualmente directa sobre el costo. El README de Anubis llama al software "un poco de una respuesta nuclear", advierte que puede bloquear scrapers más pequeños y servicios como Internet Archive, y dice a los operadores que Cloudflare será suficiente en muchos casos. Anubis existe para administradores que no pueden o no quieren hacer ese intercambio con un proveedor de borde gestionado.

Iaso también ha movido Anubis más allá de una sola página estática de prueba de trabajo. Las versiones del proyecto agregaron reglas ponderadas de petición, métodos de desafío más ligeros, correcciones específicas para navegadores, listas de bloqueo de IP y herramientas para alimentar a rastreadores sospechosos con contenido envenenado. El historial de lanzamientos refleja un proyecto que intenta clasificar el tráfico antes de forzar a cada visitante por el mismo camino costoso.

Ese trabajo trae su propia carga de mantenimiento. Iaso dijo en la entrevista de enero que Anubis seguía siendo un proyecto de noches y fines de semana a pesar de necesitar la atención de un trabajo a tiempo completo. Anubis creció porque los operadores de sitios pequeños necesitaban alivio inmediato del tráfico de rastreadores, dejando a su creador responsable de las rarezas de los navegadores, fallos de accesibilidad y adversarios que pueden cambiar su comportamiento más rápido de lo que un proyecto voluntario puede publicar.

El costo recurrente recae sobre las personas

La crítica más fuerte de Zakaria se refiere a los visitantes que no pueden completar el desafío de JavaScript de forma fiable. Señala navegadores de texto, clientes RSS, dispositivos móviles y software sensible a la accesibilidad, y argumenta que los clientes que no ejecutan JavaScript quedan excluidos.

Zakaria modeló el costo acumulado usando una espera de dos segundos y 20 julios de energía del dispositivo por cada resolución. Bajo esas suposiciones, un millón de desafíos por día consumiría alrededor de 23 años-persona de tiempo de visitantes anualmente. Diez millones consumirían alrededor de 230 años-persona.

Esos totales son escenarios, no mediciones. Zakaria no establece cuántos desafíos de Anubis se ejecutan globalmente cada día, y la estimación de energía varía según el hardware, el comportamiento del navegador y la configuración del desafío. Su comparación del trabajo bruto es más concreta: un desafío de dificultad cuatro requiere un esperado de 65,536 hashes, que él estima en alrededor de 1.3 milisegundos en Go nativo y 130 milisegundos en JavaScript del navegador antes de la carga de la página, el arranque de workers y redirecciones.

La asimetría dará forma a la próxima generación de defensas contra bots. La prueba de trabajo sigue siendo atractiva porque es barata de verificar, se puede autoalojar y es efectiva contra rastreadores básicos. Los agentes de codificación hacen que adaptadores como anubis-fetch sean más baratos de crear, mientras que los navegadores sin interfaz proporcionan un respaldo para desafíos que no pueden reproducirse directamente.

Anubis aún compra tiempo a sitios sobrecargados. La herramienta de Zakaria establece cuánto vale ese tiempo y quién sigue pagándolo. Un desafío puede eliminar el tráfico poco sofisticado de inmediato. Una defensa sostenida requiere controles de identidad, comportamiento y tasa que hagan que cada petición automatizada sea costosa, en lugar de cargar repetidamente a los humanos que intentan leer la página.