Reports
BAJA[TLS Y CRIPTOGRAFÍA]#4136767

curl con Schannel conserva la identidad del certificado de cliente tras una redirección gracias a la reanudación de sesión TLS

En curl 8.23.0 con Schannel, la reanudación de sesión TLS mantenía la identidad mTLS del cliente al seguir una redirección a otro origen. El investigador lo presenta como un arreglo incompleto de CVE-2026-86415.

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 fallo afecta a libcurl compilado con Schannel, el backend TLS nativo de Windows. Cuando una aplicación se autentica con certificado de cliente (mTLS) y luego sigue una redirección hacia otro origen, libcurl no debería presentar esa identidad en el destino nuevo. La reutilización de conexiones ya autenticadas se había corregido con CVE-2026-86415, pero, según el investigador, el arreglo quedaba incompleto: la caché de sesiones TLS seguía siendo otra vía.

Si se cierra la conexión física pero la sesión TLS sigue en la caché de libcurl, la conexión que se abre tras la redirección reanuda esa sesión, aunque vaya por una conexión TCP nueva. El servidor recibe entonces la identidad del certificado de cliente original, incluso después de haber desactivado la selección automática del certificado de cliente. Ocurre tanto con tickets de sesión como con reanudación por ID de sesión.

Datos del caso:

  • CVE: CVE-2026-115529 (presentado como arreglo incompleto de CVE-2026-86415).
  • Debilidad: autenticación incorrecta (Improper Authentication).
  • Severidad según el programa: baja.
  • Versión probada: libcurl 8.23.0-DEV con Schannel, sobre un runner de GitHub Actions con Windows Server 2022 y TLS 1.2.
  • Fechas: enviado el 22 de octubre de 2026 y divulgado el 26 de octubre de 2026, ya resuelto.

Pasos de reproducción

  1. Levantar en localhost un servidor HTTPS que exija certificado de cliente (mTLS).
  2. Conectarse a él con libcurl usando la opción CURLSSLOPT_AUTO_CLIENT_CERT y un certificado de cliente efímero, de modo que la conexión quede autenticada.
  3. Cerrar la conexión física pero conservar la caché de sesiones TLS de libcurl.
  4. Con el mismo easy handle, seguir una redirección HTTP que vuelve a apuntar al servidor HTTPS.
  5. Con la caché de sesiones activada, la conexión redirigida reanuda la sesión TLS autenticada sobre una conexión TCP nueva, y el servidor informa de la identidad del certificado de cliente original. Pasa igual en modo ticket TLS y en modo ID de sesión.
  6. Como comprobación, repetir la prueba con la caché de sesiones desactivada: el handshake TLS de la conexión redirigida falla porque no se presenta ningún certificado de cliente. Esa diferencia muestra que la identidad llega solo por la sesión reanudada.

Impacto

Una aplicación que siga una redirección influida por un atacante podría acceder sin querer a un endpoint protegido con mTLS usando la identidad de cliente con la que se autenticó antes. Eso podría saltarse la frontera de autenticación que se pretende mantener en las redirecciones.

Qué aprender de este caso

  • Cuando se arregla una fuga de credenciales en la reutilización de conexiones, hay que revisar también la caché de sesiones TLS: una sesión reanudada lleva consigo la autenticación del cliente aunque la conexión TCP sea nueva.
  • En clientes HTTP que siguen redirecciones, conviene comprobar qué estado autenticado sobrevive al cambio de origen: cabeceras, cookies, conexiones abiertas y también tickets o IDs de sesión TLS.
  • Para buscar fallos parecidos, compara el comportamiento con la caché de sesiones activada y desactivada: si el handshake solo falla cuando no hay caché, la identidad está pasando por la sesión reanudada.
  • Al programar, la entrada de la caché de sesiones debería quedar ligada al origen y al certificado de cliente con que se creó, para que no se reutilice en un contexto donde ese certificado no debería presentarse.