Denegación de servicio en bug bounty: qué cuenta y qué no
Guía en castellano sobre denegación de servicio en bug bounty: ReDoS, consumo de recursos, bucles y cierres, y por qué los ataques de inundación no cuentan.
Qué es
Una denegación de servicio (DoS) deja un sistema inutilizable o muy lento para sus usuarios legítimos. En bug bounty casi todos los programas excluyen los ataques de volumen, los de inundar el servicio con tráfico, porque no revelan ningún fallo del software y causan daño real.
Lo que sí se considera una vulnerabilidad es la asimetría: que una petición pequeña haga que el servidor gaste muchísimos recursos, o que una entrada concreta lo bloquee o lo cierre.
Ejemplos típicos
- ReDoS: expresiones regulares que, con ciertas entradas, tardan un tiempo exponencial en evaluarse.
- Ficheros diseñados para expandirse: archivos comprimidos que ocupan gigas al descomprimirse o XML con entidades anidadas.
- Consultas sin límite: paginación que acepta un tamaño de página enorme, o consultas GraphQL muy anidadas.
- Recursos que crecen sin control: cachés, colas o conexiones que no se liberan.
- Cierres del proceso por entradas inesperadas en programas que no se reinician solos.
- DoS persistente: datos guardados que rompen una página o una cuenta cada vez que se cargan.
Cómo se busca
- Localiza dónde el servidor procesa entradas complejas: expresiones regulares, ficheros, consultas, conversiones.
- Mide el tiempo de respuesta con entradas que crecen poco a poco. Si el tiempo crece mucho más rápido que la entrada, hay un problema.
- Prueba siempre en local o en un entorno propio cuando sea posible, con una copia del software.
Importante: no tumbes el servicio real. Demuestra el efecto con mediciones controladas (tiempos que crecen, uso de CPU en una copia local) y para antes de afectar a otros usuarios. Revisa lo que dice el programa sobre este tipo de pruebas.
Cómo se evita
- Límites en todo lo que entra: tamaño de peticiones, de ficheros, profundidad de consultas y elementos por página.
- Tiempo máximo de ejecución para operaciones costosas y motores de expresiones regulares sin retroceso exponencial.
- Descomprimir y analizar ficheros con límites de tamaño final.
- Aislar el procesado pesado para que un fallo no arrastre al resto del servicio.
Al reportarlo
Explica la asimetría con números: tamaño de la petición frente a tiempo o memoria consumidos, y cómo escala. Cuanto más claro el cálculo, menos necesidad de una prueba agresiva.
Casos reales de Denegación de servicio
Ver los 11 →Nextcloud Android: un enlace externo a FileDisplayActivity cierra la app por un usuario nulo
La actividad exportada FileDisplayActivity de la app Android de Nextcloud daba por hecho que había un usuario cargado. Un enlace o una app maliciosa podía abrirla y provocar un NullPointerException que cerraba la aplicación.
3 min
Agotamiento de memoria en el WebSocket de curl por los PONG automáticos (CVE-2026-11586)
La cola interna de respuestas PONG automáticas de curl crecía sin límite efectivo. Un servidor WebSocket malicioso podía forzar el consumo de memoria del cliente hasta provocar su caída por falta de memoria.
3 min
Khan Academy: la página de restablecer contraseña agotaba la memoria del navegador del usuario
En Khan Academy, abrir /pwreset?action=reset con la sesión iniciada hacía que la página generara sola miles de peticiones hasta agotar la memoria y bloquear el navegador de quien la visitaba.
1 min
ReDoS en Action Text de Rails: un blockquote manipulado bloquea to_plain_text con Ruby 3.1 o anterior
Una expresión regular de Action Text que convierte citas a texto plano sufría retroceso excesivo: con Ruby 3.1 o anterior, un blockquote lleno de tabuladores tardaba unos 39 segundos en procesarse.
4 min
Tor: un relé de salida malicioso deja inflado el contador de memoria de las colas Conflux tras cerrar el circuito
Al destruir un conjunto Conflux, Tor libera los mensajes fuera de orden pero no resta su coste del contador global. Un relé de salida malicioso puede inflarlo de forma acumulativa hasta reiniciar Tor, acercándose al límite MaxMemInQueues.
4 min
Basecamp para Android: una actividad exportada permitía cerrar la sesión del usuario desde otra app
La actividad StartActivity de la app de Basecamp para Android estaba exportada sin permiso, así que cualquier app del mismo móvil, sin pedir permisos, podía devolver al usuario a la pantalla de inicio de sesión de forma repetida.
4 min