# CVE-2026-109518 en APT: paquete falso y root en Debian > Un atacante en la red sustituye un paquete ya verificado durante un reintento. Debian 12 y Ubuntu 22.04 llegan expuestos de fábrica. > Por José Maldonado · Ciberseguridad · 2026-11-10 Un \`apt upgrade\` normal en Debian 12 o en Ubuntu 22.04 o posterior puede instalar un paquete que nadie firmó, siempre que alguien controle la red entre la máquina y el espejo. El fallo es CVE-2026-109518, puntúa 7,7 sobre 10 en CVSS v4 y los mantenedores de apt lo consideran crítico porque el resultado es código ejecutado como root. Canonical y Debian publicaron los paquetes corregidos el 4 de noviembre. El aviso de Ubuntu lo firma la [ficha oficial de CVE-2026-109518 en APT](https://ubuntu.com/security/CVE-2026-109518) y la corrección de Debian viaja en DSA-6607-1, con versiones concretas para bookworm y trixie. Lo que hace interesante el caso es la condición que dispara todo: los reintentos del cliente. APT viene configurado con \`Acquire::Retries\` en 3 desde Debian 12 y Ubuntu 22.04 LTS, un ajuste pensado para que una descarga no se caiga cuando el espejo tose. Es precisamente ese reintento es el que abre la puerta. Quien esté en medio puede dejar que el paquete se verifique y cambiar el contenido justo después, cuando el cliente vuelve a pedirlo. Los scripts de mantenimiento del paquete se ejecutan como root sin que nadie vuelva a comprobar la firma. El resultado es una instalación que parece normal en los registros y que deja el sistema en manos de quien controlaba el cable. ## El mecanismo, sin adornos APT descarga un paquete, comprueba su hash contra el índice firmado y lo deja listo para instalar. Si la descarga se corta, el reintento pide el archivo de nuevo, y si el servidor responde con una redirección cuyo destino ya existe en la caché local, APT reutiliza el archivo previo para no volver a bajarlo. Ahí está el error: dos descargas distintas comparten un mismo nodo de enlace duro y la segunda puede escribir sobre el contenido ya verificado. Max Justicz descubrió el fallo y la [descripción del seguimiento de Debian](https://security-tracker.debian.org/tracker/CVE-2026-109518) lo resume en dos vectores: inyección por redirección y sustitución mediante enlaces duros reutilizados. El [boletín QSB-122 de Qubes OS](https://www.qubes-os.org/news/2026/11/06/qsb-122/) existe porque sus plantillas Debian y Whonix heredan el problema. Ahí aparece el detalle práctico: en Qubes los repositorios van por HTTPS por defecto, así que el segundo vector desaparece y el primero sigue vivo si alguien cambió la configuración a mano. La conclusión útil es que HTTPS reduce el riesgo, pero no arregla el fallo. Solo el paquete nuevo lo hace, y la prueba está en la versión instalada, no en el mensaje final del upgrade. ## ¿Quién está expuesto de verdad? Debian 12 y 13, Ubuntu 22.04, 24.04, 26.04 y 26.10, y cualquier derivada que use apt con reintentos activos. Las versiones más antiguas quedan fuera del riesgo por defecto porque traen \`Acquire::Retries\` en cero, aunque cualquier Dockerfile o script de CI que lo haya subido las devuelve al grupo de afectados. Ese es el punto que más se está pasando por alto en las conversaciones internas. Los equipos de integración continua y las imágenes de contenedor son justo donde alguien sube el número de reintentos para que la compilación no falle contra un espejo lento. La [ficha de AWS](https://aws.amazon.com/security/security-bulletins/2026-172-aws/) lo trata como un problema de flota y no de escritorio: instancias, imágenes de contenedor y AMIs de aprendizaje profundo, con AMIs actualizadas previstas para el 13 de noviembre y ParallelCluster 3.16.3 para el 16. Los números que hay que buscar son concretos. Debian 12 necesita apt 2.6.2 y Debian 13, 3.0.4. Ubuntu 22.04 se corrige con 2.4.15ubuntu0.1, la 24.04 con 2.8.4ubuntu0.1, la 26.04 con 3.2.1ubuntu0.1 y la 26.10 con 3.3.3ubuntu0.1. Las versiones 20.04 y anteriores tienen parche por Ubuntu Pro. El mismo tipo de error de verificación ya apareció en el [CVE-2026-98432 del kernel de Linux](https://observatorioblockchain.com/ciberseguridad/cve-2026-98432-kernel-tcp-ubuntu-rhel-sin-parche/), donde Ubuntu y RHEL también tardaron en publicar paquete. ## Actualiza tu sistema Aquí está la trampa que conviene leer dos veces: la orden que instala el apt corregido se ejecuta con el apt vulnerable. Canonical recomienda desactivar los reintentos para esa actualización concreta, y [ese orden](https://www.stepsecurity.io/blog/cve-2026-109518-apt-package-swap-root) importa más de lo que parece. En la práctica se traduce en dos comandos: \`apt update\` y luego \`apt upgrade -o Acquire::Retries=0\`, repetido en cada host que no venga de una imagen ya corregida. Después, comprobar la versión con \`apt –version\`, porque el mensaje de éxito de un upgrade no dice qué versión quedó. [Ese orden](https://www.stepsecurity.io/blog/cve-2026-109518-apt-package-swap-root) no es un detalle de estilo: la actualización que cierra el fallo se ejecuta con el apt todavía vulnerable. El segundo paso es de higiene y vale para siempre: pasar los repositorios a HTTPS donde siga habiendo HTTP. La misma lección que dejó [el fallo de OpenSSH en sistemas musl](https://observatorioblockchain.com/ciberseguridad/openssh-sshole-cve-2026-123158-musl-contrasena/) aplica aquí: el paquete actualizado no basta si el servicio sigue corriendo con el binario viejo. No sustituye al parche, pero elimina el vector más fácil y evita que el próximo fallo de este tipo encuentre la misma puerta abierta. El tercero es aburrido y necesario: revisar los registros de los últimos días buscando instalaciones que nadie programó. Un paquete instalado fuera de la ventana de mantenimiento, o dos instalaciones del mismo paquete separadas por minutos, son la huella típica de un reemplazo durante un reintento. ## Lo que este fallo enseña sobre la cadena de suministro La cadena de suministro se suele contar como una historia de dependencias comprometidas y cuentas de mantenedor robadas. Este caso es más incómodo porque no hay ningún tercero malicioso en la cadena: hay una función de reintento razonable que, combinada con una redirección, rompe la garantía de que lo verificado es lo instalado. Los sistemas que sobreviven a ese tipo de fallo son los que verifican dos veces y tratan la caché como material no confiable. APT lo hacía razonablemente bien hasta que el atajo del enlace duro ahorró una descarga, y ese atajo es exactamente lo que el parche elimina en las versiones 2.6.2 y 3.0.4 de Debian y en las cuatro compilaciones de Ubuntu. La lección para quien administra flotas no es desconfiar de apt, sino recordar que la verificación y la instalación son dos momentos distintos. Cualquier cosa que ocurra entre ambos es superficie de ataque, aunque el proceso parezca interno. ## Tareas pendientes Ni Debian ni Ubuntu informaron de explotación en el momento de publicar los avisos, y eso es una buena noticia con fecha de caducidad: el fallo es silencioso, no deja un error visible y encaja en cualquier red interna con espejos HTTP. La comprobación de que nadie lo usó pasa por mirar qué se instaló, desde dónde se descargó y si el espejo configurado sigue siendo el que el equipo de sistemas cree que es. Para quien administre flotas, el trabajo de esta semana es de inventario: qué hosts siguen con la versión antigua, qué imágenes de contenedor hay que reconstruir y qué scripts de CI tienen el reintento subido. La respuesta correcta no es apagar los reintentos para siempre, sino dejarlos en cero mientras se actualiza apt.