Reports
BAJA[DENEGACIÓN DE SERVICIO]#4112912

CVE-2026-111481: una cookie del servidor aún rompe el cookie jar de curl pese al parche de CVE-2026-92386

El parche de CVE-2026-92386 no bastó: un servidor puede hacer que curl guarde una línea de cookie demasiado larga, de modo que las siguientes ejecuciones fallan con el código 100 y, con -b y -c sobre el mismo fichero, el jar se queda sin cookies.

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

Este reporte demuestra que la corrección de CVE-2026-92386 (commit 445aa87e13) dejó el problema a medias. Tras ese cambio, el analizador del fichero de cookies acepta líneas de hasta MAX_COOKIE_LINE + 48 bytes, pero una línea de 5047 caracteres o más sigue sin poder cargarse.

El límite no cubre todos los casos porque una línea guardada contiene más cosas que la cabecera Set-Cookie: también incluye el dominio y la ruta. Cuando el servidor no los indica en la cabecera, no cuentan para el límite de longitud de Set-Cookie, pero sí acaban escritos en el fichero. Así, un servidor puede fijar una cookie con un valor de 4000 bytes y sin Path en una URL cuya ruta mida 1500 bytes, y curl guarda una línea de 5539 caracteres que después no es capaz de leer.

La consecuencia es peor que lo que describe el aviso de CVE-2026-92386 ("silently abort parsing"). Desde el commit 3f0629ca4 (versión 8.18.0), un error al cargar el fichero de cookies hace fallar la transferencia. La siguiente ejecución que lea ese jar termina de inmediato con este error, sin llegar a enviar ninguna petición:

(100) A value or data field grew larger than allowed

Si además el mismo fichero se pasa a -c, esa ejecución fallida lo reescribe sin ninguna cookie.

El investigador lo reprodujo de la misma forma con tres compilaciones en Debian forky/sid x86_64:

  • curl master 9a6d4ffc1 (2026-10-13), compilación de depuración.
  • La etiqueta curl-8_22_0, compilada desde git.
  • El paquete de Debian 8.23.0~rc3-1, construido a partir de 8.23.0-rc3.

Según el reporte, la versión publicada 8.22.0 se comporta igual con estos pasos.

Pasos de reproducción

La prueba usa hdrsrv.py, un pequeño servidor HTTP adjunto al reporte original: responde a cualquier ruta que contenga /set con la cabecera que recibe por línea de órdenes, y a las demás rutas con un 200 sin más.

  1. Arrancar el servidor para que envíe una cookie de 4000 bytes sin Path, y crear un jar con dos cookies normales:
python3 hdrsrv.py 8080 srv.log Set-Cookie \
  "big=$(python3 -c 'print("v"*4000)'); Max-Age=86400" &
printf '127.0.0.1\tFALSE\t/\tFALSE\t2000000000\tone\t1\n' > jar
printf '127.0.0.1\tFALSE\t/\tFALSE\t2000000000\ttwo\t2\n' >> jar
  1. Visitar una URL con un segmento de 1500 caracteres seguido de /set, leyendo y guardando en el mismo jar:
curl -b jar -c jar "http://127.0.0.1:8080/$(python3 -c 'print("a"*1500)')/set"
# exit code 0; after the header comments, the first cookie line is now
# the 5539-character "big" cookie (cookie_output() writes newest first)

La orden termina bien (código de salida 0). Tras los comentarios de cabecera, la primera línea de cookies del fichero es ya la cookie big, de 5539 caracteres, porque cookie_output() escribe primero las más nuevas.

  1. Hacer otra petición cargando el jar:
curl -b jar http://127.0.0.1:8080/check
# exit code 100, no request reaches the server; the same on every later run

Falla con el código 100 y la petición no llega al servidor. Lo mismo ocurre en todas las ejecuciones posteriores.

  1. Repetir la petición usando el jar también como salida:
curl -b jar -c jar http://127.0.0.1:8080/check
# exit code 100 again, and the jar is rewritten with no cookies

Vuelve a fallar con el código 100, y esta vez el fichero queda reescrito sin ninguna cookie.

Impacto

Cualquier servidor que el usuario visite puede hacer que fallen todas las ejecuciones posteriores de curl que lean ese fichero de cookies, hasta que el usuario borre la línea a mano. Con la configuración habitual -b jar -c jar el daño es mayor: la ejecución siguiente borra todas las cookies guardadas, las de cualquier sitio.

El investigador también rebate una nota del aviso de CVE-2026-92386, según la cual el servidor no puede controlar en qué posición cae su línea. Sí puede: una cookie nueva se escribe la primera. Solo una cookie que sustituye a otra ya existente conserva la posición anterior.

En resumen, el impacto de CVE-2026-92386 sigue siendo alcanzable después del parche, y desde la versión 8.18.0 el resultado es una transferencia fallida y un jar vacío, no unas cookies omitidas. HackerOne lo clasifica con severidad baja. El investigador sugiere CWE-1284 (validación incorrecta de la cantidad indicada en la entrada), aunque la plataforma no le dejó seleccionarlo; la debilidad registrada es Improper Input Validation.

Qué aprender de este caso

  • Cuando un formato guarda más campos de los que recibe, el límite de entrada no garantiza nada sobre la salida. Aquí se medía la cabecera Set-Cookie, pero la línea guardada incluía también dominio y ruta. Compara siempre el tamaño máximo que puedes escribir con el que tu lector acepta.
  • Los campos que el programa rellena por defecto también cuentan. Al omitir Path, la ruta sale de la URL de la petición y no de la cabecera. Busca valores derivados de la petición que se añadan después de validar la longitud.
  • Revisa qué hace el flujo de error con los ficheros de estado. Si una carga fallida deja la lista vacía y el guardado final se ejecuta igual, un solo registro malo destruye el fichero entero: conviene no sobrescribir un fichero que no se ha podido leer.
  • Al verificar un parche de un límite de tamaño, no pruebes solo el caso del reporte anterior: busca la combinación de campos que produzca la entrada más larga posible, porque un margen fijo como MAX_COOKIE_LINE + 48 puede quedarse corto.