APT CVE-2026-109518: cómo saber si ya lo tienes corregido

El 4 de noviembre de 2026 Canonical publicó el CVE-2026-109518, un fallo de APT que, según el propio CVE, deja instalar un paquete sin verificar. Lo cuentan Ubuntu, en el aviso USN-8996-1, y el equipo de APT, en su aviso en la lista deity.

Lo Probado es del 7 de noviembre, en Ubuntu 24.04 y con ficheros míos. Lo demás es Revisado, no ejecutado (así distingo ambas cosas).

¿Qué falla en APT y a quién afecta?

Según el aviso de APT, quien controle un punto de la ruta puede provocar redirecciones y errores HTTP pasajeros. Eso fuerza reintentos, que APT hace por defecto desde la 2.3.2 (Acquire::Retries). Al reanudar, reutiliza un enlace duro y sobrescribe un fichero ya verificado. El CVE lo describe como ejecución remota de código como root.

El arreglo está en el commit 5af16a8: los métodos de descarga abren ahora el fichero de destino en exclusiva. Lo reporta Max Justicz. La ficha de CVE.org, firmada por Canonical como CNA, le da un CVSS 4.0 de 7,7 (alta).

• 4 de noviembre, 14:25 UTC: apt 2.8.4ubuntu0.1 llega a noble-security, según Launchpad.
• 4 de noviembre, 15:49 UTC: Canonical publica el CVE en CVE.org.
• 5 de noviembre, 07:22 UTC: el mismo paquete llega a noble-updates.

Para Debian está el DSA-6607-1 y el seguimiento del CVE, que da la versión corregida de cada edición. El DSA solo cita trixie, con la 3.0.4. Yo no lo he probado en Debian.

¿Cómo sé si mi APT ya lo trae corregido?

En Ubuntu 24.04 la versión corregida es la 2.8.4ubuntu0.1; la USN indica la de cada edición. El changelog del paquete sí cita este CVE, y lo comprobé: el de 2.8.4ubuntu0.1 lo nombra en la línea 5 y el de 2.8.3 no.

# Versión instalada y versión candidata (solo mira, no instala)
apt policy apt | head -4

# Si la línea sale, tu paquete ya cita el arreglo en su changelog
zcat /usr/share/doc/apt/changelog.gz | grep -m1 CVE-2026-109518

Si la versión instalada es anterior a la corregida de tu edición, actualiza. Con --only-upgrade la orden no instala APT donde no lo hubiera y no toca otros paquetes:

sudo apt update
sudo apt install --only-upgrade apt libapt-pkg6.0t64

# Confirma que la versión nueva quedó instalada
apt --version | head -1

¿Qué probé exactamente?

No monté el ataque completo. Probé el comportamiento que el arreglo cambia: qué hace APT al descargar sobre un destino que es enlace duro de otro fichero. Descargué los paquetes apt y libapt-pkg6.0t64 de 2.8.3 y de 2.8.4ubuntu0.1 y los desempaqueté en directorios aparte, sin instalarlos.

Con el apt-helper download-file de cada versión descargué desde un servidor HTTP mío en 127.0.0.1, con soporte de Range. Los hashes SHA-256 de las dos versiones corregidas coinciden con el índice de noble-updates.

Cada caso parte de un fichero ajeno de 34 bytes («FICHERO AJENO QUE NO DEBE TOCARSE») y un destino que es su enlace duro, es decir, con el mismo inodo.

• Descarga nueva, apt 2.8.3: el destino y el fichero ajeno siguen compartiendo inodo y el ajeno pasa a tener 1600 bytes, con el contenido del servidor.
• Descarga reanudada con respuesta 206, apt 2.8.3: el fichero ajeno pasa de 722 a 1600 bytes, mismo inodo.
• Enlace simbólico, apt 2.8.3: el enlace se mantiene y el fichero al que apunta pasa de «AJENO» a contener datos del servidor.
• Los tres casos con apt 2.8.4ubuntu0.1: el fichero ajeno queda con 34 bytes (o 722 en el caso reanudado) y sin cambios. El destino aparece con un inodo nuevo y, en el caso del enlace simbólico, es ya un fichero normal.

También probé la versión vulnerable con Acquire::Retries=0: el fichero ajeno subió igualmente a 1600 bytes. La escritura sobre el enlace no depende de esa opción. Lo que la opción cambia, según el aviso de APT, es cuántas veces puede forzar el atacante el reintento que desencadena la cadena completa, y eso no lo he probado.

Vuelta atrás y lo que no he probado

Mis pruebas no instalaron nada: los paquetes se desempaquetaron en /tmp, los ficheros eran míos y el servidor se paró al terminar. Si actualizas y algo falla, apt install apt=VERSIÓN_ANTERIOR libapt-pkg6.0t64=VERSIÓN_ANTERIOR baja las dos, con la versión que te mostró apt policy antes de actualizar. Volver a una APT vulnerable solo tiene sentido como medida temporal.

• El ataque completo con un intermediario en la red, y que lleve a ejecución de código como root.
• Debian y las demás ediciones de Ubuntu: solo he leído sus avisos.
• Alguna mitigación sin actualizar: el aviso de APT no da ninguna y no la recomiendo.
• El hash del paquete 2.8.3: no lo contrasté con ningún índice.

Mi lectura, que es opinión: es un parche de los que se aplican hoy y sin dudar, porque no hay que reiniciar. Si te interesa lo que hacer cuando Ubuntu aún no tiene arreglo, mira el caso del Vghost o el del bloqueo de algif_aead.