Una falla en la forma en que curl gestiona las cargas HTTP/2 permite que un servidor malicioso que recibe una subida corrompa la memoria del cliente, y el investigador que la reportó logró convertir ese fallo en ejecución de código en la máquina que realiza la carga.
El proyecto curl lo solucionó el 14 de octubre en la versión 8.23.0. Para tomar el control de un cliente se necesita un conocimiento exacto de su compilación y diseño de memoria, y curl considera que un ataque real probablemente terminaría en un fallo (crash).
La vulnerabilidad, un use-after-free registrado como CVE-2026-92392, afecta a curl y libcurl desde la versión 8.12.0 hasta la 8.22.0, tanto a la herramienta de línea de comandos como a la biblioteca que muchos otros programas emplean para transferencias. curl la clasifica como Alta en su escala de cuatro niveles, su primer fallo de gravedad Alta desde el desbordamiento de heap en SOCKS5 de octubre de 2023. El proyecto acortó su ciclo de lanzamiento en dos semanas para distribuir la corrección.
El ataque se ejecuta desde el lado del servidor. El cliente debe subir un archivo de aproximadamente 135 KB mediante HTTP/2 a un servidor controlado por el atacante, y el certificado de dicho servidor debe superar las comprobaciones del cliente. libcurl negocia HTTP/2 por defecto para URL https:// cuando el servidor lo ofrece, y la biblioteca se compiló con soporte para HTTP/2.
La falla ha estado presente en todas las versiones de curl desde la 8.12.0, lanzada en febrero de 2025. Ninguna fuente reporta ataques que la aprovechen. El informe del reportero en HackerOne, con el script del servidor malicioso y un contenedor Docker descrito como reproductor de la ejecución de código, se hizo público el 14 de octubre junto con el aviso.
Qué instalar y qué hacer mientras tanto
Actualice a la versión 8.23.0 o aplique el commit de corrección a una compilación local. El aviso legible por máquina de curl también enumera versiones corregidas en tres ramas anteriores, y el proyecto anunció que publicaría versiones actualizadas de Rock-solid curl, su línea de soporte a largo plazo para clientes con contratos de soporte, junto con la 8.23.0:
- curl y libcurl 8.12.0 a 8.22.0: actualizar a 8.23.0
- Rama 8.14.x: 8.14.3
- Rama 8.16.x: 8.16.2
- Rama 8.20.x: 8.20.2
- Debian 13 (trixie): 8.14.1-2+deb13u7 a través de DSA-6558-1, según el rastreador de Debian. Debian 12 (bookworm) no contiene el código vulnerable.
La versión corrige 24 CVE en total. Los otros 23 están clasificados como Baja gravedad.
Si aún no puede actualizar, el consejo de curl es no usar HTTP/2. La opción –http1.1 solicita la herramienta HTTP/1.1, y las aplicaciones configuran CURLOPT_HTTP_VERSION a CURL_HTTP_VERSION_1_1. La documentación de curl califica esa configuración como una petición, porque puede reutilizarse una conexión existente en otra versión.
El soporte de HTTP/2 en libcurl es una opción de compilación. Una compilación sin él no puede negociar HTTP/2, por lo que no puede alcanzar la ruta de carga que describe el aviso.
Cómo un servidor hostil convierte el error en ejecución de código
Daniel Stenberg, desarrollador principal de curl, explicó el error en una publicación difundida con el lanzamiento, y el informe público detalla la ruta del código. HTTP/2 transporta varias transferencias sobre una misma conexión, y libcurl rastrea cada transferencia con un objeto que denomina easy handle.
Durante una carga, el servidor detiene la transferencia poniendo la ventana HTTP/2 a cero, devuelve parte de la respuesta y luego reinicia el flujo manteniendo la conexión abierta. curl interpreta el reinicio como un motivo para reintentar.
En la limpieza, curl primero indica a la capa HTTP/2 que la transferencia ha finalizado y luego vacía el resto de la carga no enviada en la misma conexión. Sin una transferencia registrada, esos bytes sobrantes se leen como una nueva solicitud. El patrón de líneas que el reportero incluye en el archivo subido hace que parezcan líneas de solicitud. Cuando eso ocurre, se abre un nuevo flujo que almacena un puntero al easy handle.
El reintento se completa en una nueva conexión HTTP/1.1 y la aplicación libera el handle. La conexión antigua aún conserva el puntero y lo utiliza cuando el servidor envía una trama en ese flujo, lo que puede suceder mientras el programa finaliza.
En el exploit del reportero, los datos que envía el servidor aterrizan en la memoria que había usado el handle liberado. Una solicitud saliente filtra direcciones locales, que el servidor necesita para derrotar la aleatorización del diseño del espacio de direcciones (ASLR). Un puntero a función en esa memoria se sobrescribe con bytes del servidor, y curl lo llama.
La ejecución de código requiere que el atacante conozca la versión exacta de curl del objetivo, la arquitectura, el asignador de libc y el diseño del heap, que mantenga dos transferencias paralelas con la sincronización correcta y que ajuste la carga útil a unos 23 bytes, según el aviso de curl. "El resultado más probable de un intento de ataque es simplemente un fallo", escribió Stenberg, quien calificó la probabilidad de éxito como remota. Por eso curl otorgó a la falla la calificación Alta en lugar de Crítica.
curl utiliza cuatro niveles de gravedad y no publica una puntuación CVSS. La Base de Datos Nacional de Vulnerabilidades no había analizado el registro al 14 de octubre.
La corrección consiste en una reordenación de seis líneas en lib/multi.c realizada por Stefan Eissing. La capa HTTP/2 ahora libera sus referencias al handle después de que se hayan vaciado los datos de carga sobrantes, no antes.
El informe llegó a curl el 15 de septiembre a través de HackerOne, y el equipo de seguridad lo confirmó en pocas horas, según Stenberg. El 7 de octubre, el proyecto preanunció una corrección de gravedad Alta para el siguiente lanzamiento, acortando su ciclo de ocho a seis semanas.
curl atribuye el hallazgo a "Luna with Claude, Anthropic". Stenberg identifica a la reportera como Luna Tong, de Anthropic, señala que el hallazgo llegó a través del nuevo OSS Scanner de la compañía y presume que sus modelos de IA estuvieron involucrados.
Anthropic abrió OSS Scanner el 8 de octubre como un servicio opcional que escanea proyectos de código abierto inscritos con sus modelos y envía los resultados por correo sin revisión humana, cada informe con un reproductor y, cuando está disponible, un parche candidato. El informe de curl llegó tres semanas antes de ese lanzamiento público. La publicación de lanzamiento de Anthropic citó a Stenberg diciendo que el escáner había descubierto "una de las peores vulnerabilidades de curl reportadas en los últimos años", sin nombrar ninguna.
El mismo mantenedor escribió en julio de 2025 que alrededor de una quinta parte de los envíos de seguridad de curl ese año eran lo que él llamó "AI slop", y que solo aproximadamente uno de cada veinte había resultado genuino.
curl ha pasado varios años reduciendo el número de punteros internos a handles en favor de identificadores que busca cuando es necesario, escribió Stenberg, y eso no es garantía contra otro use-after-free. curl califica el error como un fallo que un lenguaje de memoria segura probablemente habría evitado, y el proyecto no planea reescribir curl en uno.
Deja una respuesta