Reports
ALTA[DENEGACIÓN DE SERVICIO]#3400140

Discourse: borradores gigantes en /drafts.json que saturaban el servidor de try.discourse.org

El endpoint POST /drafts.json de Discourse aceptaba y guardaba borradores de cientos de miles de caracteres, aunque respondiera 502. Con varios a la vez, un usuario autenticado llevaba las respuestas del servidor por encima de 32 segundos.

Resumen
Resumen en castellano de un reporte público, no una traducción literal. El código y los comandos se mantienen como en el original.

Resumen

Discourse guarda automáticamente lo que escribes como borrador mientras redactas un mensaje. Esa función se apoya en el endpoint:

POST /drafts.json

El investigador dpaysm comprobó en la instancia de demostración try.discourse.org que este endpoint no limitaba bien el tamaño del contenido. Al enviar un borrador con un texto enorme (unos 800.000 caracteres o más), el servidor tardaba en procesarlo, acababa devolviendo un 502 Bad Gateway... y aun así el borrador quedaba guardado.

La clave está en el contraste con la publicación normal: ese mismo texto no se podía publicar como mensaje porque la validación lo rechazaba, pero la ruta de borradores no aplicaba la misma restricción. Repitiendo la operación con varios borradores distintos, el backend se saturaba y las peticiones llegaban a tardar más de 32 segundos.

Es un caso de consumo de recursos sin control (CWE-400). El programa lo clasificó con severidad alta, lo dio por resuelto y pagó recompensa, aunque el importe no es público. El reporte se envió el 26 de octubre de 2025 y se divulgó el 30 de junio de 2026.

Pasos de reproducción

  1. Iniciar sesión en try.discourse.org con una cuenta de prueba.
  2. Empezar a escribir un mensaje y capturar con un proxy (por ejemplo, Burp Suite) la petición que guarda el borrador:
POST /drafts.json
  1. Sustituir el contenido del borrador (el campo data o el texto del borrador) por una cadena muy larga, de unos 800.000 caracteres o más.
  2. Enviar la petición. El servidor responde 502 Bad Gateway, pero si se consultan los borradores (desde la interfaz o con una petición GET) se ve que se ha guardado igualmente.
  3. Crear más borradores con el mismo contenido gigante, cada uno con una clave o identificador distinto (por ejemplo, numerándolos) para evitar el error de "ya se está editando". En la prueba se usaron 9 borradores en total.
  4. Enviar esas peticiones una tras otra o en paralelo.
  5. Medir los tiempos de respuesta: las siguientes peticiones se van ralentizando hasta alcanzar 32,108 segundos.

Impacto

Cualquier usuario con cuenta podía:

  • Obligar al servidor a procesar y almacenar textos enormes que la validación normal de mensajes habría rechazado, y hacerlo además aunque la petición terminara en error 502.
  • Encadenar varios borradores grandes en poco tiempo y provocar retrasos generales de más de 32 segundos por petición.
  • Si lo automatizaba con scripts, varias cuentas o varias IP, agotar los recursos del backend hasta dejar el foro sin respuesta para los usuarios legítimos.

Como la saturación afecta al servidor en conjunto, el efecto no se queda en el endpoint de borradores: alcanza a otras rutas y a otros usuarios de la misma instancia.