Vulnerabilidad en curl (CVE-2026-1965)

libcurl puede en algunas circunstancias reutilizar la conexión incorrecta cuando se le pide que realice una solicitud HTTP o HTTPS autenticada con Negotiate.<br /> <br /> libcurl cuenta con un grupo de conexiones recientes para que las solicitudes posteriores puedan reutilizar una conexión existente y evitar la sobrecarga.<br /> <br /> Al reutilizar una conexión, una serie de criterios deben cumplirse primero. Debido a un error lógico en el código, una solicitud emitida por una aplicación podría reutilizar erróneamente una conexión existente al mismo servidor que fue autenticado usando credenciales diferentes. Una razón subyacente es que Negotiate a veces autentica *conexiones* y no *solicitudes*, al contrario de cómo HTTP está diseñado para funcionar.<br /> <br /> Una aplicación que permite la autenticación Negotiate a un servidor (que responde queriendo Negotiate) con &amp;#39;user1:password1&amp;#39; y luego realiza otra operación al mismo servidor también usando Negotiate pero con &amp;#39;user2:password2&amp;#39; (mientras la conexión anterior sigue activa) - la segunda solicitud reutilizó erróneamente la misma conexión y dado que luego ve que la negociación de Negotiate ya está hecha, simplemente envía la solicitud a través de esa conexión pensando que usa las credenciales de user2 cuando de hecho sigue usando la conexión autenticada para user1...<br /> <br /> El conjunto de métodos de autenticación a usar se establece con &amp;#39;CURLOPT_HTTPAUTH&amp;#39;.<br /> <br /> Las aplicaciones pueden deshabilitar la reutilización de conexiones de libcurl y así mitigar este problema, usando una de las siguientes opciones de libcurl para alterar cómo las conexiones son o no son reutilizadas: &amp;#39;CURLOPT_FRESH_CONNECT&amp;#39;, &amp;#39;CURLOPT_MAXCONNECTS&amp;#39; y &amp;#39;CURLMOPT_MAX_HOST_CONNECTIONS&amp;#39; (si se usa la API curl_multi).