Esta mañana Debian publicó el DSA-6607-1 y, de nuevo, es apt: existe una falla (CVE-2026-109518) que le permite a un atacante man-in-the-middle reemplazar un paquete después de que la verificación ya pasó, y terminar ejecutando código como root en tu máquina. Y el detalle que lo hace irresistible: el bug lo encontró Max Justicz, el mismo investigador que en enero de 2019 publicó el RCE de apt en la última década (CVE-2019-3462). Siete años de diferencia, el mismo blanco: la maquinaria de descargas, no las firmas.
Cómo se salta la verificación
El flujo sano es de manual: apt baja el .deb, lo compara contra los hashes del metadato firmado y, si calza, lo instala como root. El agujero nuevo está en la costura entre esos pasos. Según el aviso oficial, apt puede fusionar dos descargas distintas cuando un redirect HTTP termina entregándoles la misma URI, y el manejo del archivo al reanudar una descarga interrumpida queda mal resuelto. O sea: dos escritores apuntando al mismo archivo de destino, y en esa ventana el contenido se puede cambiar con la verificación ya cruzada. Nadie rompió las firmas; ganaron una carrera de tiempo.
El fix es corto y dice mucho del problema: los métodos de descarga ahora abren el archivo de destino en modo exclusivo, para que dos descargas no puedan escribir sobre el mismo target a la vez. El mismo update también corrige varios accesos fuera de límites adicionales en apt.
Quién está en riesgo
El escenario requiere estar en medio de la red entre tu máquina y el origen de los paquetes. Los más expuestos: los que tiran de espejos por http plano, los que actualizan desde redes no confiables (wifi público, redes compartidas, tránsito hostil) y quienes pasan por proxies o redirectores que alguien pudo manipular. Si tu VPS usa sources en https desde tu casa o tu datacenter de confianza, el escenario típico no te toca. Pero no es típico y no es posible no son la misma frase, y en seguridad esa diferencia es la que manda.
Los derivados tienen que esperar. Chequeé una de mis máquinas Ubuntu: apt 2.8.3, y a esta hora el repositorio todavía no me oferta una versión corregida. Debian 13 (trixie) queda arreglado en apt 3.0.4 y Debian 12 (bookworm) también recibió su versión corregida, pero si estás en un derivado, revisa cuándo llega el parche a tu distro en vez de asumir que ya está.
Siete años y la misma lección
El bug de 2019 era distinto pero de la misma familia: un man-in-the-middle podía inyectar líneas nuevas en el header Location de un redirect y corromper el protocolo interno de apt, con la misma consecuencia: código como root mientras instalabas cualquier paquete. La mitigación que se recomendó entonces — apt -o Acquire::http::AllowRedirect=false — sigue siendo válida hoy si no puedes parchear todavía, con el mismo pie de letra del que la escribió en 2019: si tu espejo redirectea por defecto, ese flag te corta el update y vas a tener que apuntar a un mirror que no.
Lo que me incomoda es la arquitectura, no el bug puntual. Dos RCE en siete años, y los dos nacieron de la misma zona: el pipeline de descargas y su manejo de estado compartido. Verificar hashes es la parte fácil y está resuelta hace dos décadas; la parte difícil es todo lo que pasa alrededor de la verificación — reanudaciones, redirects, concurrencia — y ahí sigue habiendo lógica de los noventa conviviendo con expectativas de 2026. No le echo la culpa a Debian: el parche fue coordinado y salió rápido. Pero cuando la misma persona te devuelve siete años después a la misma puerta, la conclusión no es «parchea y olvídate»: es que esa superficie necesita una redisección, no un parche acumulativo.
Para cerrar, el estado actual: no hay PoC público ni explotación reportada en la naturaleza, y el análisis técnico detallado todavía no sale. Eso no cambia el cálculo. Un apt update && apt upgrade cuesta un minuto y te deja fuera de la lista de los que apuestan a que el MITM no los está mirando. Yo ya lo corrí en mis servidores; si administras Debian, hazlo ahora.
Fuente de inspiración: [SECURITY] [DSA 6607-1] apt security update
