curl avisa de un fallo grave y yo tengo cuatro libcurl

El 7 de octubre Daniel Stenberg avisó en su blog de que curl 8.23.0 saldrá el 14, unas semanas antes de lo previsto. Corrige 22 vulnerabilidades y una, CVE-2026-92392, tiene gravedad alta. Qué hace ese fallo no se sabrá hasta la mañana del 14, hora europea.

No puedo parchear un fallo que no conozco. Sí puedo saber, antes de que llegue, cuántas libcurl hay en el servidor web, quién las tiene cargadas y quién las actualiza. Esperaba encontrar una. Hay cuatro.

Qué he mirado y qué no he tocado

Lo Probado lo ejecuté el 11 de octubre de 2026, entre las 13:15 y las 13:30 UTC, en el servidor web: Ubuntu 24.04.5 LTS, kernel 6.8.0-138. Lo que sale del blog de curl, de su política de avisos o de Ubuntu va como Revisado (lo explico en cómo pruebo y reviso las guías).

Todo ha sido lectura: find, dpkg, ldd y /proc. No he actualizado ni reiniciado nada. La única descarga fue un paquete antiguo de Ubuntu, desempaquetado en un directorio de trabajo para comparar huellas, sin instalarlo.

Qué significa «alta» en curl

curl no usa CVSS. Tiene cuatro niveles (baja, media, alta y crítica) y su política de avisos despacha la alta en una línea:

This issue is in itself a serious problem with real world impact.

Política de avisos de curl, nivel High

No es frecuente. Según Stenberg, desde 2021 solo han publicado dos CVE de gravedad alta. El último, CVE-2023-38545, era un desbordamiento de memoria en el saludo con proxies SOCKS5 que afectaba de la 7.69.0 a la 8.3.0. Se corrigió en la 8.4.0, el 11 de octubre de 2023.

Lo que dice mi curl

Una LTS de Ubuntu no suele cambiar de versión a mitad de vida: la 24.04 se queda en curl 8.5.0 y le aplica los parches encima. Así que el número de versión cuenta solo media historia:

# La version de la herramienta y la del paquete, que es la que cuenta
curl --version | head -2
dpkg-query -W -f='${Version}\n' libcurl4t64

# Lo que ve PHP: solo el numero de arriba
php -r 'echo curl_version()["version"], "\n";'

# curl 8.5.0 (x86_64-pc-linux-gnu) libcurl/8.5.0 OpenSSL/3.0.13 ...
# Release-Date: 2023-12-06, security patched: 8.5.0-2ubuntu10.15
# 8.5.0-2ubuntu10.15
# 8.5.0

La segunda línea la añade Ubuntu: la fecha de la 8.5.0 original (6 de diciembre de 2023) y el paquete con los parches. PHP solo ve «8.5.0». Un escáner que compare ese número con 8.23.0 dará la máquina por perdida; uno que se fíe de él, quizá por sana. Ninguno sabe qué hay.

Cuatro libcurl, no una

Busqué todas las copias del disco y de quién es cada una. Un fichero que no pertenece a ningún paquete no lo va a actualizar apt:

# Todas las libcurl y modulos curl, sin salir de este sistema de ficheros
sudo nice find / -xdev \( -path /proc -o -path /sys \) -prune -o \
     \( -name 'libcurl*.so*' -o -name 'curl.so' \) -print

# De que paquete es cada una
dpkg -S /usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0 \
        /opt/alt/curlssl/usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0 \
        /var/www/vhosts/chroot/usr/lib/libcurl.so.4

# Contra que libcurl enlaza el modulo curl de cada PHP de Plesk
ldd /opt/plesk/php/8.3/lib/php/modules/curl.so | grep curl

Salieron 16 rutas. Ocho son módulos: el curl.so de cada PHP de Plesk, del 7.4 al 8.5, y un complemento de collectd. Todos enlazan la libcurl de Ubuntu. El resto, quitando enlaces simbólicos, son cuatro librerías:

• libcurl4t64, la de OpenSSL. La de Ubuntu, la que carga casi todo.
• libcurl3t64-gnutls, la misma versión compilada contra GnuTLS.
• alt-libcurlssl 8.22.0, en /opt/alt, del repositorio de TuxCare. Viene con Imunify: dependen de ella imunify-antivirus y su PHP interno. Esta no parchea una versión vieja: lleva el número de curl tal cual.
• La plantilla chroot de Plesk, en /var/www/vhosts/chroot. dpkg -S no encuentra paquete.

La cuarta no la esperaba. Plesk la usa para el shell enjaulado de SSH: copia programas y librerías del sistema a esa plantilla, y de ahí a cada suscripción que lo active. Aquí no lo tiene ninguna. Pero el fichero lleva fecha del 20 de agosto, y su huella no es la de la libcurl actual.

La copia que nadie actualiza

Para ponerle versión bajé de Launchpad el paquete anterior, 8.5.0-2ubuntu10.13, y comparé:

# Solo para comparar: dpkg-deb -x desempaqueta, no instala
curl -sSfLO https://launchpad.net/ubuntu/+archive/primary/+files/libcurl4t64_8.5.0-2ubuntu10.13_amd64.deb
dpkg-deb -x libcurl4t64_8.5.0-2ubuntu10.13_amd64.deb x
sha256sum x/usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0 \
          /var/www/vhosts/chroot/usr/lib/libcurl.so.4 \
          /usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0

# eac8f2e9aa13017d...  x/.../libcurl.so.4.8.0           (10.13)
# eac8f2e9aa13017d...  /var/www/vhosts/chroot/.../libcurl.so.4
# cf6398ebba028cc7...  /usr/lib/.../libcurl.so.4.8.0    (10.15)

Idéntica a la 10.13. Le faltan los cuatro CVE que nombra el registro de cambios de la 10.15, como CVE-2026-82209 (cookies fijadas para un sufijo público entero, tipo co.uk). Quien active mañana el shell enjaulado heredará una libcurl anterior al último parche.

Plesk publica un guion para rehacerla, update-chroot.sh. He leído su código, no lo he ejecutado: --update solo copia las librerías que faltan, así que esta seguiría igual; --rebuild borra la plantilla y la rehace desde el sistema.

Quién la tiene cargada

Que apt cambie el fichero no cambia lo que ya está en memoria. Un proceso que cargó libcurl antes de actualizar sigue con la vieja hasta que se reinicia, y en su /proc/<pid>/maps aparece marcada (deleted). Este guion cuenta quién la tiene y cuál:

#!/bin/sh
# Que procesos tienen libcurl en memoria ahora mismo, y cual.
# Hace falta root para leer el maps de procesos de otros usuarios.
for m in /proc/[0-9]*/maps; do
  p=${m#/proc/}; p=${p%/maps}
  lib=$(grep -m1 -o '/[^ ]*libcurl[^ ]*\( (deleted)\)\?' "$m" 2>/dev/null) || continue
  echo "$(cat /proc/$p/comm 2>/dev/null) $lib"
done | sort | uniq -c | sort -rn

Ninguno con una libcurl borrada, que es lo que quería ver. Lo de Apache me sorprendió: no hace peticiones con curl, pero ldd dice que mod_security2 enlaza libcurl, y con eso basta. Este blog también cuenta: WordPress usa la extensión curl de PHP para sus peticiones cuando la tiene.

Cómo llegó aquí el último parche

Para saber qué esperar del 14 miré cuánto tardó la tanda anterior, la de septiembre, en llegar del proyecto a esta máquina:

Veintitrés días desde curl, veintidós de ellos hasta que Ubuntu publicó. Con uno de gravedad alta debería ir más rápido: la política de curl avisa a la lista distros de Openwall como mucho siete días antes, y en 2023 Ubuntu sacó su USN-6429-1 el mismo 11 de octubre que curl.

Después queda reiniciar, y aquí lo hace needrestart al terminar unattended-upgrades: el registro del 7 de octubre lo muestra reiniciando el panel y los PHP-FPM tras actualizar freetype. Desde el día 8, los PHP-FPM de Plesk no los reinicia él de golpe: una tarea los recarga de uno en uno, cada hora, si ve librerías borradas.

El día 14

Las órdenes, con lo que dieron hoy. La actualización a mano no la he ejecutado: no hay nada que actualizar todavía.

# 1. El parche ha llegado si el registro de cambios nombra el CVE
zgrep -c CVE-2026-92392 /usr/share/doc/libcurl4t64/changelog.Debian.gz
# hoy: 0

# 2. Sin esperar a unattended-upgrades, y solo curl (no ejecutado)
sudo apt update
sudo apt install --only-upgrade curl libcurl4t64 libcurl3t64-gnutls

# 3. Quien sigue con la vieja en memoria. -b: salida para guiones;
# -r l: solo lista, no reinicia nada
sudo needrestart -b -r l | grep SVC
sudo ./quien-carga-libcurl.sh | grep deleted
# hoy: dbus, logind, getty y unattended-upgrades, ninguno con libcurl;
# grep, sin salida

Vuelta atrás

De lo de hoy no hay nada que deshacer: solo he leído. Lo descargado para comparar se borra con rm -r x libcurl4t64_8.5.0-2ubuntu10.13_amd64.deb.

Si el paquete del 14 rompe algo, el anterior sigue en la caché de apt (comprobado: /var/cache/apt/archives/libcurl4t64_8.5.0-2ubuntu10.15_amd64.deb). Volver es sudo dpkg -i de ese fichero más apt-mark hold, para que unattended-upgrades no lo suba otra vez. No lo he probado, y deja la máquina sin el parche.

Qué no he probado

• curl 8.23.0: no existe hasta el 14.
• Si la 8.5.0 de Ubuntu está en el rango afectado. Nadie fuera del embargo lo sabe.
• Cuándo llegará 8.23.0 a alt-curlssl. Lo supongo por cómo numera TuxCare, no lo he visto.
• update-chroot.sh: leído, no ejecutado.
• Programas con libcurl enlazada de forma estática: find busca ficheros .so y no los ve. Docker está instalado pero sin imágenes; en otra máquina, cada imagen trae su propia libcurl.
• Nada en ARM ni en otra versión de Ubuntu.

Y una corrección. En la entrada de algif_aead escribí que el kernel 6.8.0-142 esperaba un reinicio. Ya no espera ese: needrestart dice que el instalado es el 146, y la máquina sigue en el 138. Es lo de libcurl a lo grande; ya lo avisaba mi checklist de Ubuntu Server: instalado no es lo mismo que en uso.

Me queda una duda. Si el aviso del 14 dice que hace falta una opción rara, este inventario habrá sido para nada esta vez. Sospecho que no del todo: la plantilla chroot seguirá ahí con su 10.13 cuando salga el siguiente. Hay más guías de este tipo en el hub de Ubuntu y Linux.