curl corrige una vulnerabilidad de alta severidad en la subida HTTP/2 que permite ejecución de código en el cliente

El proyecto curl lanzó la versión 8.23.0 el 14 de octubre para corregir una vulnerabilidad de alta severidad que permite a servidores maliciosos corromper la memoria del cliente durante las subidas HTTP/2. El fallo, rastreado como CVE-2026-92392, fue descubierto por Luna Tong de Anthropic y afecta a todas las versiones de curl y libcurl desde la 8.12.0 hasta la 8.22.0.

Qué ocurrió

Esta vulnerabilidad permite que un servidor controlado por un atacante provoque la ejecución remota de código en la máquina cliente que está subiendo datos. El ataque requiere que el cliente suba un archivo de aproximadamente 135 KB mediante HTTP/2 a un servidor malicioso cuyo certificado supere las comprobaciones estándar de validación. Aunque el impacto teórico incluye la compromisión total del sistema, los mantenedores de curl señalan que la explotación exitosa es difícil y probablemente resulte en un bloqueo (crash) en lugar de una ejecución de código en la mayoría de los escenarios reales.

El error ha estado presente en cada lanzamiento de curl desde la versión 8.12.0, publicada en febrero de 2025. Supone el primer fallo de alta severidad para el proyecto desde el desbordamiento de pila (heap overflow) en SOCKS5 de octubre de 2023. En respuesta al descubrimiento, el equipo de curl acortó su ciclo regular de lanzamientos de ocho semanas en dos semanas para entregar el parche rápidamente. Hasta la fecha no se han reportado exploits activos que utilicen esta vulnerabilidad en entornos reales.

La corrección aborda un total de 24 CVEs en este lanzamiento, aunque los otros 23 están clasificados con severidad baja. El proyecto también actualizó su línea de soporte a largo plazo, conocida como las versiones Rock-solid de curl, para alinearse con este parche de seguridad. Los usuarios en ramas antiguas soportadas deben actualizar a versiones específicas parcheadas: 8.14.3 para la rama 8.14.x, 8.16.2 para la 8.16.x y 8.20.2 para la 8.20.x.

Cómo funciona

La vulnerabilidad es un error de uso tras liberación (use-after-free) arraigado en cómo libcurl gestiona las transferencias HTTP/2. HTTP/2 permite múltiples flujos concurrentes sobre una sola conexión, y libcurl rastrea cada transferencia utilizando un objeto llamado easy handle. Durante una subida, un servidor malicioso puede detener la transferencia estableciendo el tamaño de la ventana HTTP/2 en cero, devolviendo parte de la respuesta y luego reiniciando el flujo mientras mantiene abierta la conexión subyacente. Curl interpreta este reinicio como una señal para reintentar la transferencia.

En la fase de limpieza de esta lógica de reintento, curl informaba previamente a la capa HTTP/2 de que la transferencia había finalizado antes de vaciar los datos restantes de la subida no enviados. Este orden significaba que los bytes sobrantes se escribían en una conexión sin ninguna transferencia registrada. Si estos bytes parecían líneas de solicitud HTTP, curl abriría un nuevo flujo y almacenaría un puntero al easy handle. Cuando la aplicación eventualmente liberaba el handle tras completar el reintento en una nueva conexión HTTP/1.1, la conexión antigua aún mantenía un puntero colgante (dangling pointer) a esa memoria liberada.

Un atacante podría entonces enviar datos en el flujo antiguo que aterrizaran en el espacio de memoria recién liberado. Mediante la filtración de direcciones locales para evadir la aleatorización de la distribución del espacio de direcciones (ASLR), el atacante podría sobrescribir un puntero de función en esa memoria. Cuando curl llamara posteriormente a ese puntero, ejecutaría el código del atacante. La corrección, un reordenamiento de seis líneas en lib/multi.c realizado por Stefan Eissing, garantiza que la capa HTTP/2 libere sus referencias al handle solo después de que cualquier dato restante haya sido vaciado.

Detalles clave

• Versiones afectadas: curl y libcurl 8.12.0 hasta 8.22.0.
• Versiones corregidas: Actualice a 8.23.0, o a 8.14.3, 8.16.2 y 8.20.2 para ramas antiguas.
• Vector de ataque: Servidor malicioso que recibe una subida HTTP/2 de aproximadamente 135 KB.
• Severidad: Clasificada como Alta por el proyecto curl; no se ha publicado puntuación CVSS.
• Descubrimiento: Reportado por Luna Tong de Anthropic a través de HackerOne el 15 de septiembre.
• Mitigación: Deshabilite HTTP/2 usando --http1.1 o CURLOPT_HTTP_VERSION_1_1 si no es posible aplicar el parche inmediatamente.

Por qué importa

Para ingenieros de software y equipos de DevOps, este incidente destaca los riesgos inherentes a las bibliotecas de infraestructura ampliamente utilizadas. Curl está integrado en incontables aplicaciones, desde scripts de línea de comandos hasta complejos servicios backend. Dado que libcurl negocia HTTP/2 por defecto para URLs HTTPS cuando el servidor lo soporta, muchas aplicaciones pueden ser vulnerables sin cambios explícitos de configuración. El hecho de que la vulnerabilidad requiera un entorno de compilación específico y tiempos precisos para explotarla no niega el riesgo, especialmente en ataques dirigidos contra infraestructuras conocidas.

El proceso de descubrimiento también señala un cambio en cómo se encuentran las vulnerabilidades de seguridad en el código abierto. El reportero utilizó el OSS Scanner de Anthropic, una herramienta impulsada por IA que escanea proyectos de código abierto y envía resultados sin revisión humana. Esto plantea preguntas sobre el futuro de la investigación de vulnerabilidades, a medida que los modelos de IA se vuelven capaces de identificar bugs complejos de corrupción de memoria que el fuzzing tradicional podría pasar por alto. Sin embargo, también introduce ruido, ya que los mantenedores han notado un aumento en informes generados por IA de baja calidad.

Qué puede hacer

• Compruebe su versión actual de curl ejecutando curl --version y actualice inmediatamente a 8.23.0 o a una versión de rama parcheada.
• Si no puede actualizar de inmediato, fuerce HTTP/1.1 en sus aplicaciones configurando CURLOPT_HTTP_VERSION a CURL_HTTP_VERSION_1_1.
• Verifique si su compilación de libcurl incluye soporte para HTTP/2; si no, no es vulnerable a este fallo específico.
• Monitoree los rastreadores de seguridad de Debian si utiliza Debian 13 (trixie), que recibió el parche 8.14.1-2+deb13u7 mediante DSA-6558-1.
• Revise cualquier contenedor Docker personalizado o pipelines CI/CD que empaqueten versiones antiguas de curl para transferencias de archivos.
• Considere deshabilitar HTTP/2 en servicios internos donde no sea estrictamente necesario para reducir la superficie de ataque.