Debian y Ubuntu publicaron el 04/11/2026 versiones corregidas de APT (Advanced Package Tool, el gestor de paquetes de ambas distribuciones) para cerrar la vulnerabilidad CVE-2026-109518, que permite a un atacante situado en el camino HTTP entre un servidor y su repositorio sustituir un paquete después de que APT lo haya verificado y ejecutar código como root. Para quien administra decenas o cientos de máquinas, el trabajo consiste en localizar cuáles siguen con la versión antigua, actualizarlas sin esperar al ciclo habitual y revisar por qué camino llegan los paquetes.
Las claves del fallo CVE-2026-109518 en APT en 20 segundos
- Lo descubrió Max Justicz y Julian Andres Klode lo corrigió con el aviso APT-2026-11-01 del 04/11/2026.
- Exige un atacante en el tráfico HTTP (red, proxy o mirror), redirecciones y reintentos.
- Los reintentos vienen activados por defecto desde Debian 12 y Ubuntu 22.04.
- Canonical le asigna gravedad alta (7,7 sobre 10) y no consta explotación pública.
El mecanismo lo resume el análisis de OpenSecurity sobre la vulnerabilidad de APT en Debian y Ubuntu, que parte de los avisos oficiales. Según el DSA-6607-1 (Debian Security Advisory), APT puede fusionar dos descargas de paquetes distintas cuando una redirección HTTP les asigna la misma URI. Si la descarga se reanuda, APT reutiliza enlaces duros (hard links) y el paquete ya comprobado puede cambiarse por otro. Es un ataque de intermediario o MITM (man-in-the-middle), y como los paquetes .deb se instalan con privilegios de administrador, el resultado es la ejecución de código como root.
Las condiciones acotan el riesgo. El atacante tiene que estar en el camino HTTP (en la misma red, en un proxy o controlando un mirror), el cliente debe seguir redirecciones y volver a intentar descargas, y el ajuste Acquire::Retries tiene que ser mayor que cero. Ese valor es 3 por defecto desde APT 2.3.2, que es la base de Debian 12 y Ubuntu 22.04. Klode advierte en su aviso de que muchos scripts ya lo activaban en versiones anteriores, y por eso las correcciones llegan hasta la rama 1.2. Canonical, que actúa como CNA (la entidad que asigna el identificador CVE, Common Vulnerabilities and Exposures), le da 7,7 en CVSS 4.0 (Common Vulnerability Scoring System) y Ubuntu la clasifica con prioridad alta. Las fuentes consultadas a 05/11/2026 no recogen explotación activa ni prueba de concepto pública.
Cómo inventariar qué servidores tienen un APT vulnerable
En una máquina suelta bastan dos órdenes. dpkg-query muestra la versión instalada y apt-cache policy la compara con la candidata que ofrecen los repositorios configurados:
dpkg-query -W apt
apt-cache policy aptEn una prueba hecha para este artículo en un contenedor con Ubuntu 24.04, el resultado era Installed: 2.8.3 y Candidate: 2.8.4ubuntu0.1, servida desde noble-security. Si la candidata no aparece, el problema está antes: el repositorio de seguridad no está configurado o el mirror interno todavía no la ha sincronizado. Para un script de comprobación conviene comparar versiones con la lógica de Debian y no como texto:
v=$(dpkg-query -W -f='${Version}' apt)
dpkg --compare-versions "$v" ge 2.8.4ubuntu0.1 && echo "apt $v corregido" || echo "apt $v VULNERABLE"Lenguaje del código: PHP (php)La versión de referencia cambia según la distribución, así que hay que tomarla de la tabla. Con Ansible, una orden ad hoc devuelve la versión de todo un grupo de hosts, y apt-cache policy enseña también la candidata de cada uno:
ansible debian_ubuntu -m ansible.builtin.command -a "dpkg-query -W -f='${Version}' apt"
ansible debian_ubuntu -m ansible.builtin.shell -a "apt-cache policy apt | head -3"Lenguaje del código: JavaScript (javascript)Quien ya tenga playbooks de bastionado puede añadir esta comprobación al mismo inventario. Un ejemplo de ese enfoque es la guía de GitHub para blindar un servidor Linux paso a paso con Ansible.
Versiones corregidas de APT por distribución
| Distribución | Versión corregida | Aviso |
|---|---|---|
| Debian 12 bookworm | 2.6.2 | DLA-4880-1 |
| Debian 13 trixie | 3.0.4 | DSA-6607-1 |
| Debian sid (unstable) | 3.3.6 | Sin aviso propio |
| Debian forky (testing) | Sin corregir (3.3.5) a 05/11/2026 | Pendiente de migrar 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 |
DLA es el aviso del equipo de soporte a largo plazo de Debian (Debian LTS Advisory) y USN, el aviso de seguridad de Ubuntu (Ubuntu Security Notice). Las versiones +esm pertenecen a ESM (Expanded Security Maintenance) y solo llegan con una suscripción a Ubuntu Pro. Upstream ha publicado las ramas 1.2.36, 1.4.12, 1.6.19, 1.8.2.4, 2.0.12, 2.2.5, 2.4.15, 2.6.2, 2.8.4, 3.0.4 y 3.2.1, a las que se suma la 3.3.6 en sid. Las derivadas que compilan su propio APT tendrán que publicar su paquete.
Actualizar en bloque y comprobar unattended-upgrades
Para corregir el fallo basta con actualizar el paquete apt. OpenSecurity propone, como precaución si la red no es de confianza, desactivar los reintentos durante esa misma operación con -o. En la prueba con Ubuntu 24.04, estas dos órdenes pasaron APT de 2.8.3 a 2.8.4ubuntu0.1:
sudo apt-get -o Acquire::Retries=0 update
sudo apt-get -o Acquire::Retries=0 install --only-upgrade aptLenguaje del código: JavaScript (javascript)En flota, un playbook corto actualiza solo APT y devuelve la versión final de cada host. Los módulos apt y package_facts necesitan el módulo python3-apt en el nodo, para el intérprete de Python que use Ansible:
- hosts: debian_ubuntu
become: true
tasks:
- name: Actualizar solo APT
ansible.builtin.apt:
name: apt
state: latest
only_upgrade: true
update_cache: true
- name: Leer paquetes instalados
ansible.builtin.package_facts:
- name: Mostrar versión de APT
ansible.builtin.debug:
msg: "{{ inventory_hostname }}: apt {{ ansible_facts.packages['apt'][0].version }}"Lenguaje del código: JavaScript (javascript)En los servidores con actualizaciones automáticas el parche debería entrar solo, porque llega por el canal de seguridad. Conviene confirmarlo y no darlo por hecho:
cat /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump APT::Periodic
systemctl list-timers 'apt-daily*'
sudo unattended-upgrade --dry-run --debug 2>&1 | grep -i 'allowed origins'
grep -h ' apt:' /var/log/apt/history.logLenguaje del código: PHP (php)Los dos valores de 20auto-upgrades deben estar a «1». Si apt-config dump muestra APT::Periodic::Enable "0", el script diario de APT termina sin hacer nada (algunas imágenes de contenedor lo traen así). En Ubuntu, la simulación debe listar el origen -security de la versión, y en Debian lo define Origins-Pattern en 50unattended-upgrades. Los servidores Ubuntu 20.04 o anteriores solo recibirán la corrección si tienen Ubuntu Pro activado. El ritmo de parches de Canonical ya se había acelerado este año, como contaba el artículo sobre las actualizaciones del kernel de Ubuntu ante el aumento de CVE detectadas con IA.
Repositorios HTTP, mirrors internos y la medida temporal
El ataque necesita manipular tráfico HTTP, así que interesa saber qué fuentes no van cifradas. Hay que mirar en los dos formatos: las líneas deb clásicas de sources.list y los ficheros deb822 .sources, donde la dirección va en el campo URIs:
grep -rnE '^s*deb(-src)?s+([[^]]*]s+)?http://' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null
grep -nE '^URIs:.*http://' /etc/apt/sources.list.d/*.sources 2>/dev/nullLenguaje del código: PHP (php)En la instalación de prueba de Ubuntu 24.04, ubuntu.sources apuntaba por HTTP tanto a archive.ubuntu.com como a security.ubuntu.com. La firma de los repositorios sigue funcionando, pero este fallo consiste justo en cambiar el paquete después de verificarlo. Pasar a HTTPS reduce la exposición frente a un atacante en la red local, aunque, como señala OpenSecurity, no protege si el mirror o el proxy ya son maliciosos. La solución completa es la versión corregida.
Acquire::Retries=0 como medida provisional
La descripción oficial del CVE indica que el ataque requiere un valor de Acquire::Retries distinto de cero. A partir de esa condición, OpenSecurity recoge como medida temporal fijarlo a 0 en los equipos que no se puedan parchear todavía. El coste es que las descargas fallarán más en conexiones inestables, así que debe retirarse al instalar la versión corregida:
echo 'Acquire::Retries "0";' | sudo tee /etc/apt/apt.conf.d/99-cve-2026-109518-retries
apt-config dump Acquire::Retries
# Tras actualizar APT:
sudo rm /etc/apt/apt.conf.d/99-cve-2026-109518-retriesLenguaje del código: PHP (php)Un detalle para la verificación: en una instalación por defecto, apt-config dump Acquire::Retries no devuelve nada, porque el valor 3 viene compilado en APT y no figura en la configuración. Una salida vacía no significa que los reintentos estén desactivados.
Mirrors internos y apt-cacher-ng
El CVE menciona de forma expresa un mirror o un proxy malicioso como vía de ataque, lo que convierte esos servidores en infraestructura sensible. En redes con un mirror propio, lo primero es confirmar que ha sincronizado el canal de seguridad (bookworm-security, trixie-security, noble-security, etc.), porque si no, apt-cache policy no ofrecerá la candidata corregida en ningún cliente. Con un proxy de caché como apt-cacher-ng, que escucha por defecto en el puerto 3142, los clientes suelen hablar con él por HTTP. Para saber qué servidores pasan por un proxy:
apt-config dump | grep -iE 'Acquire::(http|https)::Proxy'Lenguaje del código: JavaScript (javascript)El propio servidor del mirror o del proxy suele ser un Debian o un Ubuntu y también necesita su APT actualizado. Además, conviene limitar quién puede escribir en él y en qué segmentos de red puede situarse un equipo entre los clientes y la caché.
Preguntas frecuentes
¿Cómo sé si mi servidor tiene la versión de APT vulnerable?
Basta con ejecutar apt-cache policy apt y comparar la versión instalada con la de la tabla. En Ubuntu 24.04 la corregida es la 2.8.4ubuntu0.1, en Debian 12 la 2.6.2 y en Debian 13 la 3.0.4.
¿Están afectados Debian 11 o Ubuntu 20.04?
Con la configuración por defecto no, porque los reintentos no venían activados antes de APT 2.3.2. Aun así, hay parches para Ubuntu 20.04 a 14.04 vía Ubuntu Pro, porque muchos scripts activaban ese ajuste a mano.
¿Basta con poner Acquire::Retries a 0?
Elimina una de las condiciones que exige el ataque, pero es una medida provisional. La solución es instalar la versión corregida de APT y retirar después ese ajuste.
¿Se está explotando ya?
Las fuentes consultadas a 05/11/2026 no informan de explotación activa ni de pruebas de concepto públicas.
Fuentes:
- OpenSecurity: Debian y Ubuntu corrigen un fallo en APT que permite colar paquetes vía MITM
- Julian Andres Klode: APT-2026-11-01 security update
- Debian: DSA-6607-1 apt security update
- Debian LTS: DLA-4880-1 apt security update
- Debian Security Tracker: CVE-2026-109518
- Ubuntu: CVE-2026-109518
- Ubuntu: USN-8996-1 APT vulnerability
