curl airea sus fallos menores: qué cambia en Ubuntu 24.04

vuln:LOW y vuln:MEDIUM son dos etiquetas del gestor de incidencias de curl en GitHub. A las 06:16 UTC de este lunes, 26 de octubre, no tenían ni una incidencia. Desde hoy es en ese gestor donde curl quiere ver, en público y desde el primer día, sus fallos de seguridad de gravedad baja y media.

Me interesa qué cambia para quien tiene un Ubuntu 24.04, que lleva curl 8.5.0 con soporte hasta 2029. He contado cuántos CVE de curl le afectan, cuántos ha parcheado Ubuntu y con qué retraso, y cuándo cruza la otra raya que curl acaba de pintar: la de los tres años.

Lo Probado es del 26 de octubre de 2026, entre las 06:16 y las 06:46 UTC. La política de curl y las notas de Ubuntu son Revisado: leídas, no ejecutadas (así los distingo).

Qué cambia en curl desde hoy

Daniel Stenberg, fundador y desarrollador principal de curl, lo propuso el sábado 17 de octubre en una discusión del repositorio: «Today (a Saturday) we received 13 vulnerability reports. We cannot handle managing them in secret within our tiny team».

Según Stenberg en la discusión, los CVE y sus avisos siguen saliendo con la versión que los corrige, y a la lista de distribuciones la avisa la semana antes; dice que podría seguir haciéndolo con lo bajo y lo medio. Lo nuevo es que el informe y su arreglo se discuten a la vista desde el principio.

Quien dude de la gravedad puede empezar en HackerOne, dice la política, y si curl lo ve bajo o medio le pedirá que lo lleve a GitHub.

Por qué lo hacen

En la misma discusión, Stenberg contó que hoy alrededor del 60 % de los informes resultan ser un fallo o una vulnerabilidad confirmada. El 22 añadió en otra entrada que en los últimos meses han recibido cientos, todos con IA de por medio en algún grado. Para él es cuestión de supervivencia:

This is deemed a necessary step to make the curl security team survive.

Daniel Stenberg, en la discusión del 17 de octubre

No los llama basura. Dice que eso prácticamente se acabó en primavera y que ahora el problema es «high volume, high quality». En agosto de 2025, en la charla de la foto de portada, la diapositiva todavía hablaba de «slop attacks». A mí el cambio me parece sensato para un equipo tan pequeño. Me inquieta más la otra mitad.

La otra raya: tres años

El 18 de octubre, en medio de la discusión, Stenberg pidió otra cosa: «I also want us to officially stop caring about older releases». Al día siguiente entró en la política, con un commit que lo explica así: «There has to be a line in the sand somewhere». La raya quedó en esto:

«Low or Medium severity vulnerability reports restricted to releases older than three years are out of scope and are closed without action. We do not have bandwidth to also manage lost causes.»

VULN-DISCLOSURE-POLICY.md de curl, apartado «Old releases»

En la tabla, la curl de las LTS de Ubuntu y de las dos últimas Debian. Las fechas salen de la tabla de versiones de curl; el recuento de CVE, de mi primer guion, y coincide con la columna «Vulns» de esa tabla.

Ubuntu 24.04 tiene soporte estándar hasta mayo de 2029, y 26.04 hasta mayo de 2031, según el calendario de Canonical. Las dos pasarán más de dos años con una curl al otro lado de la raya. Ubuntu 22.04 y Debian 12 ya lo están.

Lo que se queda al otro lado

Ojo a lo que dice la regla: habla de fallos que solo afectan a versiones viejas. Uno que siga en la 8.23.0 entra igual, y su aviso cubre el rango entero. Lo que queda fuera es código que curl ya cambió, y la política lo justifica con un «older issues have likely been remediated».

Me escama otra cosa del mismo fichero. Un problema que solo salga con una dependencia antigua deja de contar como fallo de seguridad, pero solo si ya no la usa «any existing still supported operating system or distribution». Para las versiones de curl no hay esa condición. Sospecho que una LTS con ese código se quedará sin aviso de curl.

Cuántos CVE de curl tiene encima la 8.5.0

curl publica todos sus CVE en un JSON con formato OSV, con la lista de versiones afectadas de cada uno. Contar los de una versión es filtrar esa lista. Así lo hice, con la salida al final, en comentarios:

# Todo en una carpeta de trabajo; no hace falta sudo
mkdir -p ~/vigilar-curl && cd ~/vigilar-curl

# La lista de CVE de curl, en formato OSV: un fichero JSON público
curl -sfO https://curl.se/docs/vuln.json

# Cuántos afectan a cada versión (la de Ubuntu 24.04 es la 8.5.0)
for v in 7.81.0 7.88.1 8.5.0 8.14.1 8.18.0; do
  python3 - "$v" <<'EOF'
import json, sys, collections
v = sys.argv[1]
cves = [e for e in json.load(open("vuln.json"))
        if any(v in a.get("versions", []) for a in e["affected"])]
sev = collections.Counter(e["database_specific"]["severity"] for e in cves)
print(v, len(cves), dict(sev))
EOF
done

# 7.81.0 78 {'Low': 51, 'Medium': 26, 'High': 1}
# 7.88.1 66 {'Low': 49, 'Medium': 16, 'High': 1}
# 8.5.0 55 {'Low': 41, 'Medium': 14}
# 8.14.1 60 {'Low': 46, 'High': 1, 'Medium': 13}
# 8.18.0 58 {'Low': 44, 'High': 1, 'Medium': 13}

La 8.5.0 carga con 55, ninguno alto: 41 bajos y 14 medios. Las otras cuatro tienen uno alto: CVE-2023-38545 (SOCKS5) las dos más viejas, y CVE-2026-92392, el de la 8.23.0, las dos más nuevas.

Son cuentas de curl sobre la versión original; lo que haya parcheado cada distribución va aparte. En Ubuntu 26.04, por ejemplo, el alto de la 8.23.0 quedó corregido el 14 de octubre, según su rastreador y Launchpad.

Qué ha parcheado Ubuntu

Ubuntu no sube de versión: aplica parches sobre la 8.5.0 y los apunta, con su CVE, en el changelog. Ese fichero viaja dentro del paquete, recortado en una entrada de julio de 2019, así que basta con cruzar las dos listas:

# El changelog del paquete instalado guarda todas las entradas desde 2019
CL=${CL:-/usr/share/doc/libcurl4t64/changelog.Debian.gz}
zcat "$CL" | grep -o 'CVE-[0-9]*-[0-9]*' | sort -u > parcheados.txt

# Los CVE de la 8.5.0 que el changelog no nombra
python3 - 8.5.0 <<'EOF' > sin-mencion.txt
import json, sys
v = sys.argv[1]
parcheados = set(open("parcheados.txt").read().split())
afectan = [e["aliases"][0] for e in json.load(open("vuln.json"))
           if any(v in a.get("versions", []) for a in e["affected"])]
faltan = [c for c in afectan if c not in parcheados]
print(f"{v}: {len(afectan)} CVE, {len(afectan) - len(faltan)} en el changelog", file=sys.stderr)
print("\n".join(faltan))
EOF
cat sin-mencion.txt

# 8.5.0: 55 CVE, 43 en el changelog
# (siguen 12 líneas con un CVE cada una: las mismas del bloque siguiente)

CL apuntaba al changelog de libcurl4t64 8.5.0-2ubuntu10.16, la última de noble-security (14 de octubre), sacado del .deb con dpkg-deb -x tras comprobar su sha256 con el índice del repositorio. En una máquina al día, la ruta por defecto es ese mismo fichero; el changelog completo está en la web.

Para los doce que faltan, el rastreador de Ubuntu tiene un JSON por CVE, con el estado en cada versión:

# Qué dice el equipo de seguridad de Ubuntu de cada uno, para 24.04 (noble)
while read -r cve; do
  curl -sf "https://ubuntu.com/security/cves/$cve.json" | python3 -c '
import json, sys
d = json.load(sys.stdin)
for p in d["packages"]:
    if p["name"] == "curl":
        for s in p["statuses"]:
            if s["release_codename"] == "noble":
                print(d["id"], s["status"], s["description"])'
  sleep 1   # sin prisa: una petición por segundo
done < sin-mencion.txt

# CVE-2026-107928 not-affected see notes
# CVE-2026-92390 not-affected see notes
# CVE-2026-86410 not-affected see notes
# CVE-2026-87865 not-affected see notes
# CVE-2026-87866 not-affected see notes
# CVE-2026-80231 not-affected see notes
# CVE-2026-19931 not-affected see notes
# CVE-2026-12064 not-affected code not present
# CVE-2025-10966 not-affected code not compiled
# CVE-2025-5025 not-affected code not present
# CVE-2025-0725 not-affected only with old zlib
# CVE-2024-2466 not-affected code not compiled

Los doce figuran como no afectados. Las notas de cada uno dicen por qué:

• Cuatro dependen de wolfSSL, wolfSSH o mbedTLS, y Ubuntu compila curl solo con OpenSSL y GnuTLS.
• Dos tocan a la verificación de SSH y no se dan con libssh, que es lo que usa Ubuntu en lugar de libssh2.
• Uno necesita WebSockets, que Ubuntu no compila hasta 26.04.
• Uno solo pasa en Windows y macOS, y otro solo con zlib 1.2.0.3 o anterior.
• Uno pide combinar -J con -i o -I, y esta curl ya lo rechaza.
• CVE-2026-12064 figura como «code not present», sin más nota.
• En CVE-2026-19931, la nota cuenta que curl revirtió su propio arreglo y se quedó con documentar el comportamiento, así que la 8.22.0 sigue haciéndolo. Ubuntu da sus versiones por no afectadas porque se portan igual que la de curl.

Con qué retraso

Crucé la fecha de cada aviso de curl con la primera publicación en noble del paquete que nombra el CVE, sacada de Launchpad. Ese guion se queda en mis notas; esto es lo que dio:

La mediana esconde los extremos. En las tandas de marzo y octubre de 2026, Ubuntu publicó el mismo día que curl; los cinco CVE de enero tardaron 48 días, y dos de los de junio, 56 y 61. No sé por qué unas tandas van tan deprisa y otras no.

Y CVE-2025-0167, uno bajo de credenciales de .netrc, tardó 399: curl lo avisó el 5 de febrero de 2025 y Ubuntu lo parcheó en la 10.8, el 11 de marzo de 2026.

La 8.5.0 de Ubuntu no es la de curl

El dato raro es CVE-2026-87862. curl no da la 8.5.0 por afectada, porque el fallo nació en la 8.11.0, pero Ubuntu lo parcheó en la 10.16. Su nota lo explica:

«Jammy and noble are affected because CVE-2024-9681.patch backports the upstream change that introduced this flaw.»

Nota del equipo de seguridad de Ubuntu en CVE-2026-87862

La 8.5.0 de Ubuntu lleva código de la 8.11.0. Cuando la 8.5.0 cumpla tres años, la de Ubuntu seguirá teniendo dentro código de versiones más jóvenes. Un fallo que solo exista en esa mezcla no se reproduce en ninguna versión de curl, y no sé en qué lado de la raya caería.

Cómo vigilar las dos etiquetas

Para ver lo nuevo sin esperar a la versión, basta con preguntar a la API de GitHub por las dos etiquetas:

# Las dos etiquetas de vulnerabilidades del gestor de incidencias de curl
for l in vuln:LOW vuln:MEDIUM; do
  curl -sf "https://api.github.com/repos/curl/curl/issues?labels=$l&state=all&per_page=50" |
    python3 -c 'import json, sys
for i in json.load(sys.stdin):
    print(i["created_at"][:10], i["number"], i["title"])'
done

# (nada: a las 06:16 UTC del 26/10/2026 las dos etiquetas estaban vacías)

A las 06:16 no devolvía nada, y a las 06:46 tampoco. Las dos etiquetas existen (la API responde 200 a cada una y describe la primera como «A vulnerability deemed severity LOW»), pero estaban vacías.

Sin token, GitHub admite 60 peticiones por hora por IP, y la cabecera x-ratelimit-limit lo confirmaba. Una consulta cada hora va sobrada. No lo he dejado programado.

Comprobación

Todo cuadra si cruzar.sh da 55 y 43 para la 8.5.0 y esto da 12 estados y ninguno distinto de not-affected:

# Guardar la salida: si ubuntu.com no responde, el recuento lo delata
bash rastreador.sh > estados.txt
wc -l < estados.txt                 # 12, una línea por CVE
grep -v not-affected estados.txt    # sin salida: ninguno ha cambiado

# 12
# (sin salida)

Si un día aparece un needed o un needs-triage, ese es el CVE que hay que mirar. Y el 55 tiene que coincidir con la columna «Vulns» de la tabla de versiones de curl, que es su propio recuento.

Vuelta atrás

En el sistema no hay nada que deshacer, porque no se ha instalado nada. Se borra la carpeta de trabajo y listo:

cd ~ && rm -rf ~/vigilar-curl

Lo que corrijo de la entrada de las cuatro libcurl

En curl avisa de un fallo grave y yo tengo cuatro libcurl escribí que la 8.23.0 «corrige 22 vulnerabilidades», que es lo que había anunciado Stenberg el 7 de octubre. Salieron 24: 23 bajas y una alta.

También dejé pendiente si la alta, CVE-2026-92392, tocaba a la 8.5.0. No le toca: según curl, entró en la 8.12.0, y Ubuntu da 24.04 por no afectada.

Qué no he probado

• Debian 12 y 13: solo he contado sus CVE en vuln.json; no he cruzado sus changelogs ni su rastreador.
• La variante GnuTLS, libcurl3t64-gnutls: sale del mismo paquete fuente y comparte changelog, pero no he abierto su .deb.
• Ni Ubuntu 20.04 o anteriores con Ubuntu Pro, ni Red Hat, Alpine o cualquier otra distribución.
• Cómo aplicará curl la regla de los tres años: no he buscado incidencias cerradas por ella.
• Cómo se usarán las etiquetas: la política no las nombra, hoy están vacías y lo que sé de ellas sale de su descripción.

Lo demás que he escrito sobre Ubuntu está en Ubuntu y Linux. Imagen destacada: Daniel Stenberg en el Open Source Summit Europe de 2025, foto de Pietro Lombardo, CC0, vía Wikimedia Commons.