curl 8.23.0 ya está disponible: comprobar la instalación real y las dependencias de SMB

curl 8.23.0 se publicó el 14.10.2026. Un curl actualizado en el terminal no demuestra que también se haya actualizado libcurl dentro de una aplicación empresarial. Los pequeños equipos de TI con scripts, contenedores y aplicaciones de proveedores deben identificar la copia utilizada, su proveedor y los criterios de aceptación funcional. Hay otra pregunta concreta: ¿alguna tarea sigue necesitando SMB?

Qué está confirmado el 14 de octubre

La tabla de versiones recoge 8.23.0 con fecha 14.10.2026 y la página de descargas ofrece sus archivos de código fuente. [1][2] Esto sustituye la indicación anterior de lanzamiento previsto; 8.23.0-rc3 no es la versión regular. La disponibilidad del código no prueba que exista un paquete en su canal ni que una biblioteca integrada esté actualizada. El número de versión tampoco basta para determinar las correcciones retroportadas de una distribución. El registro de cambios documenta la eliminación del soporte de SMB. [3] Las tareas con smb:// o smbs:// requieren inventario y comprobación funcional antes de migrar. Se refiere a curl, no automáticamente al SMB del sistema operativo.

Requisitos y límites

Se necesita acceso de lectura al inventario y a las tareas programadas, una persona responsable de la aplicación y un entorno de pruebas separado con datos no confidenciales. El inventario no requiere instalaciones administrativas ni sustituir archivos del sistema. Las actualizaciones posteriores deben seguir el canal admitido. Una libcurl incluida en una aplicación no tiene por qué ser la biblioteca de la herramienta de línea de comandos. [4] No copie binarios o DLL ajenos en las carpetas de las aplicaciones.

Cinco pasos para preparar el cambio

  1. Inventaríe el uso, no solo las versiones. Anote aplicación, contexto de ejecución, ruta, origen del paquete, responsable y finalidad de cada tarea importante. Distinga servicios, tareas programadas, ejecutores de CI y contenedores. Una ruta encontrada en la terminal personal no demuestra qué ejecuta un servicio. Para software de terceros, solicite el inventario de componentes o la confirmación del proveedor; el nombre de un archivo no basta.
  2. Identifique el ejecutable utilizado. En Windows, la consulta de solo lectura Get-Command curl.exe -All de PowerShell ayuda a localizar ejecutables; en Linux/macOS, command -v curl muestra la resolución de la shell actual. Ejecute el binario aprobado y de confianza mediante su ruta completa con --version. curl --version informa sobre bibliotecas, protocolos y funciones. [5] Registre también el motor TLS y la arquitectura. Esta consulta no inventaría otros procesos ni bibliotecas integradas por separado. command -v también puede devolver una función de la shell o un alias. Antes de consultar la versión, compruebe que la ruta registrada identifica el ejecutable aprobado.
  3. Asigne una vía de actualización a cada instalación. Los paquetes del sistema, las imágenes base, las herramientas independientes y las aplicaciones de terceros necesitan sus propios responsables. Los distribuidores pueden incorporar correcciones a versiones anteriores; el número upstream por sí solo no acredita el estado de los parches. El día del lanzamiento, compare aviso del proveedor, revisión del paquete y disponibilidad real. No sustituya la libcurl de una aplicación sin autorización del proveedor. Documente aprobaciones pendientes con responsable y fecha de revisión. [7]
  4. Prepare una pequeña matriz de pruebas funcionales. Seleccione una descarga autorizada, un caso necesario de proxy/autenticación y una respuesta de error controlada en pruebas. Defina antes el estado HTTP, el contenido esperado y el código de salida: que un proceso termine correctamente no garantiza datos correctos. Pruebe solo los protocolos necesarios, sin consultar destinos de producción arbitrarios. No introduzca secretos en líneas de comandos ni registros compartidos. Compare antes y después con la misma configuración. Novedad en 8.23.0: busque smb:// y smbs:// en scripts y configuraciones autorizados sin copiar credenciales. Una coincidencia es una posible dependencia, no prueba de uso activo. Registre la tarea, la copia real de curl y el responsable. Si SMB desaparece de la lista de protocolos tras el cambio, es una modificación documentada, no un error TLS. Acuerde con el responsable de la aplicación un cliente SMB compatible o una vía de transferencia adecuada; no cambie protocolos a ciegas. La aceptación exige que el mismo caso de prueba autorizado produzca los datos y la gestión de errores esperados por la nueva vía. [3]
  5. Programe el cambio únicamente tras la aprobación. Prepare un paquete estable compatible, copia de la configuración, ventana de mantenimiento y procedimiento de reversión comprobado. Reserve las versiones preliminares para pruebas opcionales de compatibilidad aisladas. Cambie primero una tarea representativa y compruebe ruta, biblioteca y resultado en el contexto real del servicio o contenedor. Amplíe el despliegue solo tras la aceptación. Un contenedor antiguo o proceso persistente puede seguir usando la versión anterior; planifique cualquier reinicio necesario.

Diagnosticar sin desactivar la verificación TLS

Si falla la validación del certificado después del cambio, compare reloj, nombre del servidor, cadena de certificados, motor TLS y almacén de confianza. Diferentes compilaciones pueden usar distintos almacenes de CA. No silencie el fallo con --insecure o -k: curl verifica los certificados por defecto. [6] Obtenga las CA internas únicamente mediante un canal empresarial autorizado. Ante autenticación o redirecciones inesperadas, deténgase, conserve un registro depurado del error y consulte al operador responsable.

Comprobación y vuelta atrás

El cambio termina cuando la tarea de producción utiliza de forma demostrable la instalación aprobada, supera la matriz y conserva monitorización y gestión de errores funcionales. Registre revisión del paquete, momento de ejecución y aceptación. Ante regresiones, utilice la reversión documentada del paquete o aplicación, sin intercambiar bibliotecas sueltas. Volver a una versión vulnerable no es una solución permanente: pause el proceso si hace falta y acuerde una medida temporal con seguridad. Los procesos que modifican datos también necesitan un plan de restauración coherente. Plantilla de registro, no una prueba realizada: «tarea; cuenta de servicio/contenedor; ruta completa; revisión del paquete/proveedor; dependencia de protocolo; contenido/código de salida esperados; resultado; aprobación; reversión». Sin opciones adecuadas, una respuesta de error HTTP no produce automáticamente un código de error de curl; compruebe estado, contenido y código de salida por separado. [5]

Fecha y fuentes

Información a 16.10.2026. Guía editorial basada en fuentes, no una prueba propia de compatibilidad o seguridad de curl. No se afirma un auge específico de búsquedas sobre curl 8.23.0 o SMB; sin enlaces de afiliación. Compruebe por separado el lanzamiento y la disponibilidad local del paquete; siguen siendo necesarios un canal compatible y la aprobación.