5 noviembre 2026
Cloud, Seguridad
8 minutos de lectura

El fallo de APT en Debian y Ubuntu pone a prueba cómo se parchea Linux en la nube

Antonio

Debian y Ubuntu han publicado el 4 de noviembre de 2026 nuevas versiones de APT (Advanced Package Tool, el gestor de paquetes de ambas distribuciones) para cerrar la CVE-2026-109518, un fallo que permite a un atacante situado entre el servidor y el repositorio colar un paquete manipulado e instalarlo con privilegios de root. El error exige unas condiciones de red concretas, pero toca la herramienta con la que se actualiza todo lo demás, y eso lo convierte en una buena prueba de cómo gestionan las empresas el parcheo de sus flotas Linux, sus imágenes de máquinas virtuales y sus contenedores.

Las claves del fallo de APT en Debian y Ubuntu en 30 segundos

Debian y Ubuntu publicaron el 04/11/2026 versiones de APT que corrigen la CVE-2026-109518, descubierta por Max Justicz.
Un atacante situado en el tráfico HTTP, o un mirror o proxy malicioso, puede cambiar un paquete ya verificado y ejecutar código como root.
Hacen falta redirecciones y reintentos de descarga; estos vienen activados por defecto desde Debian 12 y Ubuntu 22.04.
Canonical la puntúa con un 7,7 en CVSS 4.0 y no consta explotación ni prueba de concepto pública.

El caso lo ha detallado OpenSecurity, que recoge el aviso APT-2026-11-01 de Julian Andres Klode, mantenedor de APT y autor de la corrección para todas las ramas estables. El descubridor es Max Justicz, el mismo investigador que en 2019 encontró la CVE-2019-3462, otro fallo de APT relacionado con la manipulación de descargas. La CVE (Common Vulnerabilities and Exposures, el catálogo público de vulnerabilidades) la ha registrado Canonical como CNA (CVE Numbering Authority, entidad autorizada para asignar identificadores).

El problema está en el componente HTTP de APT. Cuando una redirección hace que dos descargas distintas acaben apuntando a la misma URI, APT puede fusionarlas. Si la descarga se corta y se reanuda, la reutilización de enlaces duros permite sustituir el paquete después de que la firma ya se haya comprobado. Es una condición de carrera de tipo TOCTOU (time-of-check to time-of-use, el intervalo entre la comprobación y el uso). Como los scripts de un paquete .deb se ejecutan como administrador, el resultado puede ser ejecución de código como root.

Qué necesita un atacante y qué versiones lo corrigen

El fallo no se explota desde cualquier parte de internet. Hace falta un ataque MITM (man-in-the-middle, de intermediario): que el atacante controle el camino HTTP entre la máquina y el repositorio, ya sea en la misma red, en un proxy comprometido o al frente de un mirror. Además, el servidor tiene que estar instalando o actualizando paquetes en ese momento, el atacante debe poder forzar redirecciones y errores transitorios, y APT tiene que reintentar las descargas.

Este último punto explica por qué afecta sobre todo a sistemas recientes. La opción Acquire::Retries vale 3 por defecto desde APT 2.3.2, la versión que llegó con Debian 12 y Ubuntu 22.04. Las versiones anteriores no están expuestas con su configuración de serie, aunque muchos administradores activaron los reintentos a mano para lidiar con mirrors inestables, y por eso las correcciones se han llevado también a ramas antiguas.

Canonical puntúa el fallo con un 7,7 sobre 10 en CVSS 4.0 (Common Vulnerability Scoring System), lo que corresponde a gravedad alta, y le asigna prioridad alta en Ubuntu. Klode lo califica de crítico en su aviso. A fecha de 5 de noviembre no consta explotación activa ni prueba de concepto pública. Según Canonical, el fallo afecta a cualquier interfaz basada en APT (apt, apt-get, aptitude o las herramientas gráficas de Ubuntu), pero no a la instalación de paquetes snap. La misma actualización corrige varios accesos a memoria fuera de límites que, según Klode, permiten como mucho una denegación de servicio en servicios como PackageKit.

Sistema	APT corregido	Aviso
Debian 12 bookworm	2.6.2	DLA-4880-1
Debian 13 trixie	3.0.4	DSA-6607-1
Debian sid	3.3.6	Sin aviso propio
Debian forky (testing)	Pendiente (3.3.5 vulnerable)	Llegará desde sid
Ubuntu 26.10	3.3.3ubuntu0.1	USN-8996-1
Ubuntu 26.04 LTS	3.2.1ubuntu0.1	USN-8996-1
Ubuntu 24.04 LTS	2.8.4ubuntu0.1	USN-8996-1
Ubuntu 22.04 LTS	2.4.15ubuntu0.1	USN-8996-1
Ubuntu 20.04 LTS	2.0.12+esm1 (Ubuntu Pro)	USN-8996-1
Ubuntu 18.04 LTS	1.6.19+esm1 (Ubuntu Pro)	USN-8996-1
Ubuntu 16.04 LTS	1.2.36+esm1 (Ubuntu Pro)	USN-8996-1
Ubuntu 14.04 LTS	1.0.1ubuntu2.24+esm4 (Ubuntu Pro)	USN-8996-1

Debian 11 y Debian 10 solo reciben la corrección a través de Extended LTS (ELTS), el soporte extendido de pago, y el proyecto APT ha publicado además las ramas 2.2.5 y 1.8.2.4. Las distribuciones derivadas que compilan su propio APT tienen que sacar sus propias actualizaciones.

Para comprobar la versión instalada y actualizar solo el paquete afectado, Canonical recomienda desactivar los reintentos durante la propia actualización, de modo que el parche no pueda ser atacado mientras se descarga:

apt list --installed '?source-package(^apt$)'
sudo apt update && sudo apt install -o Acquire::Retries=0 --only-upgrade '?source-package(^apt$)'

Flotas, plantillas e imágenes: donde APT se queda atrás

En una empresa con decenas o cientos de servidores, el parche no se aplica una vez sino en cada sitio donde vive APT. Los servidores en marcha son la parte fácil. Según Canonical, unattended-upgrades viene activado por defecto desde Ubuntu 16.04 y aplica las actualizaciones de seguridad cada 24 horas, así que los equipos con esa configuración intacta deberían tener ya la corrección. La wiki de Debian explica que la configuración por defecto instala actualizaciones de seguridad y no nuevas funciones, aunque el paquete puede no estar instalado o estar desactivado. Conviene verificarlo con sudo unattended-upgrade -d y revisar los registros de /var/log/unattended-upgrades/, porque un servicio parado no avisa.

Las ventanas de mantenimiento siguen siendo necesarias para lo que no se puede aplicar en caliente, pero este caso no requiere reiniciar. Tampoco entra en juego Livepatch: Canonical deja claro que su servicio de parcheo en caliente cubre solo el núcleo y que las bibliotecas y programas de espacio de usuario corresponden a unattended-upgrades o a una herramienta de gestión como Landscape. Livepatch reduce los reinicios por fallos del kernel, no sustituye a la actualización de paquetes.

El punto débil suele estar en lo que no está encendido. Las plantillas de máquinas virtuales, las imágenes doradas de los proveedores cloud y las imágenes base de contenedores llevan la versión de APT que tenían el día en que se generaron. Un contenedor construido hoy sobre una base de Debian 12 o Ubuntu 22.04 sin actualizar arrastra APT vulnerable, y precisamente instala paquetes durante la construcción, a menudo a través del proxy o del mirror del pipeline de integración continua. Por eso hay que reconstruir esas imágenes con la base actualizada, comprobar la versión de APT dentro de ellas y retirar del registro las que ya no deban usarse.

Versiones antiguas y Ubuntu Pro

Las ramas de Ubuntu fuera del soporte estándar dependen de Ubuntu Pro. Según Canonical, Ubuntu 20.04 y 18.04 reciben los parches mediante ESM (Expanded Security Maintenance, mantenimiento de seguridad ampliado), mientras que 16.04 y 14.04 necesitan además el complemento Legacy. Ubuntu Pro es gratuito hasta cinco máquinas para uso personal. En la práctica, una empresa que todavía mantiene servidores con 18.04 sin suscripción no recibirá esta corrección, y lo mismo ocurre con Debian 10 u 11 sin ELTS.

Mirrors, proxies y la cadena de suministro de paquetes

Muchas organizaciones no descargan paquetes directamente de los repositorios oficiales. Usan mirrors internos, cachés como apt-cacher-ng o proxies corporativos para ahorrar ancho de banda y controlar qué llega a producción. Esa pieza intermedia es justo el tipo de posición que necesita este ataque. La firma de los repositorios protege la integridad de extremo a extremo, pero aquí el paquete se cambia después de verificarlo, así que confiar solo en la firma no basta mientras APT no esté actualizado.

Canonical indica que cifrar el tráfico con HTTPS impide que un atacante intermedio manipule las descargas y propone pasar las fuentes de APT a HTTPS cuando no se pueda descartar ese riesgo. Advierte de que algunos mirrors comunitarios no admiten HTTPS. OpenSecurity añade el matiz de que HTTPS no protege si el mirror o el proxy de confianza es el que está comprometido. Una vez instalado el APT corregido, según Canonical, un mirror comprometido deja de suponer un riesgo para este fallo.

Como medida temporal en sistemas que aún no puedan actualizarse, OpenSecurity propone fijar Acquire::Retries a 0 y retirar ese ajuste tras aplicar el parche, además de revisar qué fuentes siguen usando HTTP:

echo 'Acquire::Retries "0";' | sudo tee /etc/apt/apt.conf.d/99-cve-2026-109518
grep -rn "http://" /etc/apt/sources.list /etc/apt/sources.list.d/

Inventario: saber qué está parcheado y qué no

Responder a un aviso como este exige saber qué versión de APT hay en cada servidor, plantilla e imagen. Para Debian, el Debian Security Tracker muestra el estado de cada CVE por versión de la distribución. Para Ubuntu, Canonical publica los USN (Ubuntu Security Notices) y datos OVAL (Open Vulnerability and Assessment Language) en formato legible por máquina, que herramientas compatibles con SCAP como OpenSCAP pueden usar para auditar un sistema o una imagen cloud oficial a partir de su manifiesto:

wget https://security-metadata.canonical.com/oval/com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
bunzip2 com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
oscap oval eval --report report.html com.ubuntu.$(lsb_release -cs).usn.oval.xml

La presión sobre los tiempos de parcheo no es nueva. Revista Cloud ya ha contado cómo la IA acelera la búsqueda de vulnerabilidades y obliga a replantear el parcheo, y en octubre repasó qué distribuciones y paneles habían corregido PHP2Shell. En el caso de APT, el riesgo práctico es más acotado que en otros fallos recientes, pero afecta al mecanismo que distribuye todas las demás correcciones.

Preguntas frecuentes

¿Qué versiones de Debian y Ubuntu están expuestas por defecto a la CVE-2026-109518?

Las que traen APT 2.3.2 o posterior, con Acquire::Retries en 3: Debian 12, Debian 13 y Ubuntu 22.04 en adelante. Las versiones antiguas solo quedan expuestas si alguien activó los reintentos a mano.

¿Basta con usar repositorios HTTPS para evitar el fallo?

Según Canonical, TLS impide que un atacante intermedio manipule el tráfico. OpenSecurity advierte de que no protege si el propio mirror o proxy está comprometido, así que la corrección completa es instalar la versión parcheada de APT.

¿Hay que reconstruir las imágenes de contenedores y máquinas virtuales?

Sí, si parten de una base con APT vulnerable y van a instalar paquetes. Actualizar los servidores en marcha no cambia las plantillas ni las imágenes guardadas en el registro.

¿Cómo se actualiza APT en Ubuntu 20.04 o versiones anteriores?

Esas ramas reciben la corrección como paquetes +esm a través de Ubuntu Pro, gratuito para uso personal en hasta cinco máquinas. En Debian 11 y 10 el parche llega por el programa de pago Extended LTS.

Fuentes: