Tornado 6.6 corrige un DoS en las peticiones HTTP fragmentadas
CVE-2026-115927 permite que cuerpos HTTP/1.1 con millones de fragmentos pequeños bloqueen el bucle de eventos de Tornado anterior a 6.6; la corrección está en Tornado 6.6.0.
El advisory de Tornado para CVE-2026-115927 describe una denegación de servicio en el lector de cuerpos HTTP/1.1 con transferencia fragmentada. En versiones anteriores a 6.6, el proceso puede consumir todos los fragmentos que ya llegaron al búfer sin ceder el control al bucle de eventos. Un cliente remoto puede enviar millones de fragmentos de un byte y mantener ocupado el proceso mientras Tornado los interpreta; las demás conexiones servidas por ese mismo proceso también se quedan esperando.
El detalle que convierte un cuerpo aparentemente corriente en una carga costosa es la cantidad de fragmentos, no solo el volumen final. El aviso indica que una petición cercana al límite predeterminado de 100 MB puede mantener bloqueado el proceso casi un minuto. Si un servicio acepta varias conexiones en paralelo o el atacante repite la secuencia, el efecto se amplifica sobre la disponibilidad del servicio.
-SecureCrew dice: Medir solo megabytes deja fuera el dato incómodo: a veces el coste está en cuántas veces hay que procesar el envoltorio.-
No es solo un problema de servidor
El impacto puede aparecer en más de un rol del framework. En handlers que no usan @stream_request_body, Tornado conservaba cada fragmento como un objeto separado; el aviso estima que esto podía consumir alrededor de veinte veces el tamaño recibido cuando la carga se divide en unidades mínimas. SimpleAsyncHTTPClient comparte el patrón al leer una respuesta de un servidor malicioso, así que una aplicación que actúa como cliente también debe revisar cómo usa la biblioteca.
El fallo requiere que el extremo remoto pueda enviar o proporcionar una respuesta HTTP al componente afectado, pero no requiere autenticación según la ficha del proyecto. No es una lectura de datos ni una ejecución de código: el efecto descrito es saturar el bucle y la memoria de proceso, con la interrupción de otras tareas como consecuencia. El advisory no presenta una campaña observada ni una explotación confirmada; documenta el comportamiento técnico y sus condiciones.
Qué cambia en Tornado 6.6
La corrección está en Tornado 6.6.0. El proyecto introdujo pausas periódicas durante la lectura del cuerpo, combina fragmentos pequeños antes de entregarlos a data_received y almacena de forma más compacta los cuerpos no transmitidos por streaming. GitHub Advisory Database registró y revisó esta ficha el 28 de octubre, aunque el proyecto publicó el advisory el 22 y Tornado 6.6 ya se había subido a PyPI el 21. Son tres hitos distintos: la actualización del registro no significa que el parche apareciera el día 28.
Hay una consecuencia para aplicaciones que utilizan @stream_request_body: tras la corrección, las piezas que recibe data_received ya no corresponden necesariamente a los límites de los fragmentos HTTP. Si el código de la aplicación daba por hecho que cada llamada representaba un fragmento original, esa lógica debe revisarse durante la actualización. Es un cambio de comportamiento acotado y explícito en el aviso, no un motivo para volver a asumir que la frontera del protocolo es una frontera de callback.
-SecureCrew dice: El arreglo protege el bucle de eventos; los consumidores de su API también deben dejar de tratar cada callback como si viniera con una etiqueta de transporte.-
Inventario y actualización
Los despliegues upstream anteriores a 6.6 están dentro del rango afectado del aviso; la versión corregida indicada es 6.6.0. Para instalaciones empaquetadas por una distribución Linux, hay que mirar la versión del paquete y la información de backport de ese mantenedor: una cadena de versión base antigua no basta por sí sola para concluir que el código vulnerable sigue presente, y una actualización de PyPI no actualiza automáticamente paquetes administrados por el sistema operativo.
La comprobación útil es identificar qué procesos usan Tornado como servidor y cuáles como cliente HTTP, revisar sus versiones efectivas y planificar la actualización en ambos caminos. Si una aplicación emplea streaming, conviene incluir una revisión de los handlers afectados por el cambio de agrupación de fragmentos. El límite de tamaño del cuerpo no debe tomarse como sustituto del arreglo: la vulnerabilidad depende también del trabajo que cada fragmento impone al proceso.
El advisory enlaza el problema con un único componente y un cambio concreto de parser, no con una indisponibilidad general de todas las aplicaciones Python. La exposición real depende de dónde se use Tornado y de qué interfaces reciban cuerpos HTTP o respuestas de terceros. Esa precisión permite priorizar servicios alcanzables por redes no confiables y clientes que consultan servidores externos sin convertir cualquier instalación del paquete en una caída inminente.
Diccionario de la Crew
Bucle de eventos — Mecanismo que reparte el tiempo de ejecución entre tareas de una aplicación asíncrona.
Transferencia fragmentada — Forma de enviar un cuerpo HTTP/1.1 en porciones precedidas por su tamaño, en lugar de indicar toda su longitud por adelantado.
Streaming de cuerpo — Procesamiento de una solicitud por partes a medida que llegan, sin esperar a reunir todo el cuerpo en memoria.
