JC Rueda
Ciberseguridad · Aviso

Debian/Ubuntu APT · Sustitución de paquetes ya verificados en descargas HTTP

Un fallo en APT, el gestor de paquetes de Debian y Ubuntu, permite que alguien capaz de manipular el tráfico HTTP cambie un paquete ya verificado por otro malicioso, que después se instala con permisos de root. Debian y Ubuntu ya han publicado el parche.

Publicado Lectura 9 min Ref. CVE-2026-109518 CVSS 7.7 (CNA (Canonical), CVSS v4.0, registro CVE publicado el 4/11/2026. NVD no había publicado puntuación propia en el momento de la consulta.)

Resumen

Debian (aviso DSA-6607-1) y Ubuntu (USN-8996-1) corrigieron el 4 de noviembre de 2026 la vulnerabilidad CVE-2026-109518 en APT, la herramienta que instala y actualiza software en estas distribuciones. La descubrió el investigador Max Justicz. Un atacante situado entre el equipo y el servidor de paquetes (en la misma red, en un proxy o en un mirror malicioso) puede aprovechar las redirecciones y los reintentos de descarga para sustituir un paquete después de que APT lo haya verificado, y así ejecutar código como root. Canonical la puntúa con un 7,7 sobre 10 (CVSS 4.0, gravedad alta) y no consta que se esté explotando. La solución es actualizar el paquete apt.

Materias: Vulnerabilidades, Linux, Debian, Ubuntu, Cadena de suministro de software, Ataques de intermediario (MITM), Gestión de parches

Las actualizaciones de Debian y Ubuntu están firmadas para que nadie pueda colar un paquete falso por el camino. Esa garantía tenía un hueco: APT, el programa que descarga e instala esas actualizaciones, comprobaba bien el paquete, pero luego podía acabar instalando otro distinto. El fallo, catalogado como CVE-2026-109518, ya está corregido. Explicamos a quién afecta, cómo funciona y qué hay que hacer.

Descripción

Qué es

APT (Advanced Package Tool) es el gestor de paquetes de Debian, Ubuntu y de las distribuciones basadas en ellas. Cuando un administrador ejecuta apt update y apt upgrade, o cuando el sistema se actualiza solo con unattended-upgrades, APT descarga los paquetes de software (ficheros .deb) desde los servidores de la distribución o desde sus réplicas (mirrors). Antes de instalarlos los verifica mediante firmas criptográficas, y la instalación se hace con permisos de root, es decir, de administrador total del sistema.

La vulnerabilidad CVE-2026-109518, que el mantenedor de APT llama file verification bypass (elusión de la verificación de ficheros), permite que un atacante en posición de intermediario (man-in-the-middle o MITM: alguien que puede leer y modificar el tráfico entre el equipo y el servidor) haga que APT instale un paquete controlado por él y sin verificar. El resultado es la ejecución remota de código como root. El registro CVE la clasifica como CWE-62 (mal manejo de enlaces duros de UNIX) y CWE-367 (condición de carrera TOCTOU, es decir, el fichero que se comprueba no es el mismo que luego se usa).

A quién afecta

Para que el ataque funcione tienen que darse a la vez estas condiciones:

  • El atacante debe poder manipular el tráfico HTTP de las descargas: estar en la misma red, controlar un proxy o operar un mirror malicioso. No basta con conocer la dirección IP de la víctima.
  • APT debe tener activados los reintentos de descarga (opción Acquire::Retries con un valor distinto de cero) y seguir redirecciones HTTP. Los reintentos vienen activados por defecto, con valor 3, desde APT 2.3.2, o sea, desde Debian 12 «bookworm» y Ubuntu 22.04 LTS. Según Canonical, las versiones anteriores no son vulnerables con su configuración por defecto, pero sí lo son si un administrador o un script ha activado esa opción.
  • La descarga tiene que hacerse por HTTP sin cifrar, que sigue siendo lo habitual en muchas instalaciones de Debian y Ubuntu, porque la integridad se confía a las firmas.

Versiones afectadas y corregidas

Según el registro CVE y el anuncio del mantenedor, están afectadas todas las ramas de APT anteriores a estas versiones corregidas:

  • Debian 13 «trixie» (estable): vulnerable la 3.0.3, corregida en la 3.0.4 (DSA-6607-1).
  • Debian 12 «bookworm»: vulnerable la 2.6.1, corregida en la 2.6.2 (DLA-4880-1).
  • Debian «forky» (pruebas) y «sid» (inestable): vulnerable la 3.3.5, corregida en la 3.3.6. Ya está publicada en sid. En el momento de escribir, el security tracker todavía marcaba forky como vulnerable, a la espera de que llegue la nueva versión.
  • Ramas antiguas (LTS, eLTS y Ubuntu Pro/ESM): 1.2.36, 1.4.12, 1.6.19, 1.8.2.4, 2.0.12, 2.2.5, 2.4.15, 2.8.4 y 3.2.1.
  • Ubuntu: las versiones con sufijo ubuntu0.1 o +esm indicadas en el aviso USN-8996-1, por ejemplo 2.4.15ubuntu0.1 (rama de Ubuntu 22.04 LTS), 2.8.4ubuntu0.1 (rama de Ubuntu 24.04 LTS) y 1.0.1ubuntu2.24+esm4 para Ubuntu 14.04 en Ubuntu Pro.

Mecánica

Cómo funciona el ataque

APT protege las descargas así: los ficheros de índice del repositorio (Release/InRelease) están firmados por la distribución e incluyen la huella criptográfica (hash) de cada paquete. Por eso, aunque el transporte sea HTTP sin cifrar, un intermediario no debería poder cambiar un paquete sin que APT lo detecte. El fallo no rompe la criptografía. Lo que hace es aprovechar cómo gestiona APT los ficheros en disco mientras descarga.

Según el aviso de Debian y el mensaje del mantenedor de APT, Julian Andres Klode, en la lista deity, el ataque combina varias piezas:

  1. Redirecciones HTTP. El intermediario responde con redirecciones que hacen que dos descargas distintas de paquetes acaben apuntando a la misma dirección (URI). APT termina «fusionando» ambas descargas.
  2. Errores transitorios y reintentos. El atacante simula un fallo o una interrupción de la descarga. Con Acquire::Retries activado, APT reintenta y reanuda la descarga HTTP en lugar de empezarla de cero.
  3. Reutilización de enlaces duros. Un enlace duro (hard link) es un segundo nombre para el mismo fichero en disco. Al reanudar, APT trata mal el fichero y acaba sobrescribiendo, a través de un enlace duro, un paquete que ya había pasado la verificación con el contenido que elige el atacante.
  4. Instalación como root. Como el paquete ya figura como verificado, APT se lo pasa a dpkg, que lo instala con privilegios de administrador. Los scripts de instalación del paquete malicioso se ejecutan como root.

Es un caso típico de time-of-check / time-of-use: lo que se comprueba y lo que se usa no son lo mismo. Según el registro de cambios de APT 3.3.6, la corrección consiste en que los métodos de descarga abran los ficheros de destino en modo exclusivo, de forma que no se pueda escribir encima de un fichero existente.

Qué no permite

No es un fallo que se pueda explotar desde cualquier lugar de Internet contra cualquier servidor. Hace falta controlar el tráfico de la víctima justo cuando actualiza, y que la víctima use HTTP. Eso explica el vector CVSS: AT:P (requiere condiciones previas de despliegue) y UI:P (requiere una acción de la víctima, en este caso lanzar una actualización, aunque puede ser automática). Las redes compartidas o poco fiables, los proxies corporativos comprometidos y los mirrors de terceros son los escenarios realistas.

Otros fallos corregidos en la misma actualización

Las nuevas versiones corrigen también varios accesos fuera de límites de memoria (out-of-bounds) en el análisis de paquetes .deb, de ficheros deb822, de respuestas DNS (registros SRV) y en el resolvedor de dependencias. Según el mantenedor, en la práctica su impacto se limita a la denegación de servicio, por ejemplo cuelgues de servicios como PackageKit o aptdaemon que procesan paquetes no fiables. Algunos fallos de este tipo en apt-ftparchive y en el analizador de build-profiles se han dejado sin corregir en esta tanda por su complejidad.

Respuesta del creador

Respuesta de los mantenedores

La publicación fue coordinada. El 4 de noviembre de 2026 aparecieron a la vez:

  • El aviso DSA-6607-1 del equipo de seguridad de Debian para Debian 13, que atribuye el hallazgo a Max Justicz. Es el mismo investigador que en 2019 descubrió CVE-2019-3462, otro fallo de APT ligado a las redirecciones HTTP.
  • El aviso DLA-4880-1 del equipo Debian LTS para Debian 12.
  • El aviso de Ubuntu USN-8996-1. Canonical es la CNA (autoridad que asigna el identificador CVE) que registró la vulnerabilidad.
  • Un mensaje técnico del mantenedor de APT, Julian Andres Klode, que califica el fallo como «crítico», detalla las condiciones de explotación, enumera las versiones corregidas de cada rama y explica qué fallos menores se corrigen y cuáles no.
  • La versión APT 3.3.6, que incorpora la corrección en el código principal.

Gravedad oficial

La CNA (Canonical) le asigna 7,7 sobre 10 en CVSS 4.0 (gravedad alta). El mantenedor de APT la considera crítica por el impacto (código como root), pero la puntuación oficial refleja que hace falta estar en posición de intermediario y que se den ciertas condiciones. Cuando se consultó, NVD (la base de datos de vulnerabilidades del Gobierno de EE. UU.) no había publicado una puntuación propia.

Explotación y autoridades

Ni Debian ni Canonical informan de explotación real, y la vulnerabilidad no figura en el catálogo KEV de CISA (vulnerabilidades explotadas activamente). No hemos encontrado un aviso específico de INCIBE-CERT en el momento de redactar. Tampoco consta que se haya publicado un exploit (código de ataque) público. El investigador anunció el hallazgo en redes sociales, pero no hemos localizado un informe técnico completo suyo.

Parches y mitigaciones

Qué hacer ya

  1. Actualizar el paquete apt a la versión corregida de cada distribución: 3.0.4 en Debian 13, 2.6.2 en Debian 12, 3.3.6 en sid/forky, o la versión que indique USN-8996-1 en Ubuntu. Se puede comprobar la versión instalada con apt --version o dpkg -l apt. Muchos sistemas con unattended-upgrades ya la habrán recibido automáticamente.
  2. Hacer la actualización desde una red de confianza. Mientras no esté parcheado, el propio APT sigue siendo vulnerable, también al descargar su propia actualización. Para esta actualización concreta conviene evitar redes públicas o compartidas y proxies que no se controlen.
  3. Mitigación provisional: desactivar los reintentos. El mantenedor indica que el fallo solo afecta cuando Acquire::Retries es distinto de cero, así que ponerlo a cero elimina una de las condiciones necesarias. Para una sola ejecución: 
    apt -o Acquire::Retries=0 update
apt -o Acquire::Retries=0 install --only-upgrade apt
    También se puede fijar de forma temporal en un fichero de /etc/apt/apt.conf.d/. A cambio, las descargas fallarán más a menudo en conexiones inestables. Se puede volver a activar una vez parcheado.
  4. Preferir mirrors por HTTPS. Con un mirror de confianza servido por HTTPS, un intermediario de red no puede manipular las redirecciones ni las respuestas. Esto no protege si el mirror o el proxy de terminación TLS es el malicioso, y ningún fabricante lo presenta como solución sustitutiva del parche.
  5. Revisar configuraciones antiguas. En Debian 11 o Ubuntu 20.04 y anteriores los reintentos están desactivados por defecto, pero conviene comprobar si algún script los activa (apt-config dump | grep -i retries) y aplicar las actualizaciones LTS/ESM disponibles.

En Hacker News se ha propuesto como mitigación la opción Acquire::http::AllowRedirect=false, que se usó en 2019. Como el ataque necesita redirecciones, es razonable pensar que reduce el riesgo, pero ni Debian ni Canonical la han confirmado para este caso. No debe sustituir a la actualización.

Lo que no se ha corregido

El mantenedor desaconseja usar apt-ftparchive para generar repositorios a partir de paquetes .deb no fiables, porque quedan accesos fuera de límites pendientes en esa herramienta.

Lectura jurídica

Para las organizaciones sujetas al Esquema Nacional de Seguridad, a la Directiva NIS2 o al deber de seguridad del art. 32 del RGPD, esto es un caso típico de gestión de parches. Lo razonable es documentar cuándo se aplicó la actualización a cada sistema afectado y, si no puede aplicarse de inmediato, qué mitigación se adoptó. No hay indicios de explotación, así que, salvo hallazgos concretos en los propios sistemas, no hay ningún incidente que notificar.

Fuentes