curl 8.23.0 corrige un fallo grave: revisa la biblioteca y el uso de SMB

Claves de la noticia

• curl 8.23.0 corrige 24 vulnerabilidades y publica los detalles de CVE-2026-92392, un fallo de gravedad alta ligado a las subidas por HTTP/2.
• La ejecución de código exige un servidor malicioso y condiciones específicas; el aviso también identifica ramas anteriores con la corrección incorporada.
• La actualización elimina SMB y SMBS: resolver la exposición requiere comprobar tanto la biblioteca utilizada como la compatibilidad de las transferencias.

curl ha publicado este 14 de octubre la versión 8.23.0 con una corrección especialmente relevante para las aplicaciones que suben datos mediante HTTP/2. La nueva entrega reúne 24 arreglos de seguridad y adelanta el calendario habitual. Para quienes mantienen servicios, automatizaciones o programas que integran libcurl, la decisión práctica exige revisar la biblioteca realmente desplegada y las funciones que necesita cada aplicación.

Un fallo en el cliente que controla el servidor remoto

El aviso de CVE-2026-92392 describe un error de gestión de memoria durante una subida. Una respuesta de reinicio de flujo HTTP/2 puede dejar una referencia a un objeto ya liberado. Es un use-after-free: el programa vuelve a utilizar memoria cuya vida útil había terminado. El proyecto asigna al problema gravedad alta y confirma que también afecta a la herramienta de línea de comandos.

La distinción entre cliente y servidor importa. No basta con que una empresa aloje una web que admita HTTP/2 para concluir que sus visitantes están expuestos a este fallo. El componente vulnerable es curl o libcurl cuando participa en la operación descrita. La primera pregunta del inventario debe ser qué aplicación realiza subidas y qué biblioteca utiliza para hacerlo, antes de contar dominios o servidores publicados en internet.

Según la explicación de Daniel Stenberg, fundador y principal desarrollador de curl, el servidor malicioso necesita encadenar circunstancias muy particulares del cliente. Intervienen su arquitectura, la distribución de memoria y las bibliotecas utilizadas. El autor considera difícil reproducir con éxito esa combinación fuera del entorno preparado y señala que un intento tiene más probabilidades de provocar un cierre inesperado.

Eso delimita el riesgo, pero no elimina la necesidad de corregirlo. La ejecución de código demostrada depende de condiciones concretas; no debe describirse como una intrusión automática contra cualquier instalación. Tampoco esos requisitos permiten dar por seguro un programa sin verificar su versión y su uso del protocolo. Esta revisión no ha ejecutado la prueba de explotación ni acredita ataques reales contra usuarios.

Cuatro vías de versión que conviene distinguir

El rango general del aviso abarca desde curl 8.12.0 hasta 8.22.0, ambos incluidos. Sin embargo, la misma fuente recoge excepciones para ramas de mantenimiento. Al contrastar ambas partes aparece una consecuencia operativa: un número inferior a 8.23.0 no demuestra por sí solo que esta vulnerabilidad siga presente. Hay que mirar la rama y el parche, además de la versión principal.

La tabla reproduce las excepciones del aviso; no certifica que esas versiones resuelvan cualquier otro problema de seguridad. Además, el proyecto recuerda que muchas aplicaciones emplean libcurl sin anunciarlo de forma visible. Actualizar únicamente el ejecutable que aparece al abrir una terminal no demuestra que se haya sustituido la copia integrada en otro programa. Conviene pedir al proveedor la versión efectiva y la referencia de su corrección.

La precisión del rango ya resultó decisiva en el cambio de versiones afectadas de AhsayCBS comunicado por Huntress. Son incidentes distintos, pero comparten una lección verificable para el mantenimiento: una etiqueta de versión solo sirve cuando se contrasta con el aviso actualizado del producto.

Actualizar también cambia las transferencias SMB

El registro oficial de cambios confirma que 8.23.0 elimina el soporte de SMB y SMBS. Por tanto, la migración no debe reducirse a instalar un paquete y comprobar que arranca. Si una automatización dependía de esas transferencias, esa función requiere una alternativa. El cambio de compatibilidad pertenece a la entrega; no es una condición del fallo de HTTP/2.

De ahí que existan dos comprobaciones diferentes: acreditar la corrección de seguridad y conservar las operaciones necesarias. El aviso ofrece actualizar, aplicar el parche o evitar HTTP/2. Elegir una rama mantenida o una corrección del proveedor exige documentación específica; desactivar un protocolo también requiere comprobar que la aplicación funciona en esa configuración. Ninguna de estas opciones justifica deshabilitar la validación de certificados.

En organizaciones españolas que dependen de integradores o software empaquetado, la pregunta útil al soporte es concreta: qué componente libcurl incorpora la aplicación, qué actualización resuelve CVE-2026-92392 y qué transferencias cambian después. Como mostró el incidente de sistemas Danfoss y su recuperación, disponer de un parche y recuperar una operación comprobada son tareas relacionadas que necesitan evidencias propias.

De 22 arreglos previstos a 24 publicados

El adelanto del 7 de octubre anunciaba 22 vulnerabilidades pendientes. El anuncio definitivo de la versión eleva el total a 24. La comparación de ambos documentos arroja dos correcciones adicionales; no permite concluir que todas tengan la misma gravedad ni que aparecieran después de aquel adelanto.

Stenberg publica también una presentación de la entrega. El título, la descripción y la autoría comprobados identifican el repaso de las vulnerabilidades y cambios; no se atribuyen aquí explicaciones concretas a un minuto del vídeo. Puede consultarse en curl 8.23.0 con Daniel Stenberg, en su canal oficial.

La conclusión para el despliegue es concreta: la evidencia de corrección debe identificar la copia de libcurl y su rama, y acompañarse de una comprobación de compatibilidad si se utilizaba SMB. El número total de fallos explica la importancia de la entrega; ese doble control explica cómo evaluar su aplicación en un servicio real.

Imagen: recreación conceptual generada con IA para Tecnología Today; no representa una instalación afectada.