El paquete que se verifica y luego se cambia

Anteayer se publicó CVE-2026-109518 en APT el gestor de paquetes de Debian y Ubuntu.
Un atacante en medio de la conexión o un mirror malicioso, sustituye el paquete justo después de que APT lo haya verificado y antes de que lo instale.
El resultado se instala como root.
Afecta a Debian 12 y 13 incluso a Ubuntu 22.04 en adelante en configuración por defecto.
Ya hay parche en DSA-6607-1 (threatdefence.com).
Lo llamativo no es el desbordamiento ni la firma rota sino donde ocurre te lo digo en 3 cositas:
-
La verificación criptográfica de APT funciona, es decir… el paquete que se comprueba es auténtico.
-
Pero…el que se instala, un instante después, ya no lo es.
-
Entre esos dos momentos hay una ventana que nadie estaba mirando.
No es un caso aislado
La misma semana trae el mismo patrón en otro sitio.

CISA metió en KEV CVE-2026-119977, una carrera TOCTOU en las rutas de staging de una actualización completa de WordPress Core.
TOCTOU significa time-of-check to time-of-use, el tiempo entre comprobar y usar (thehackernews.com).
Durante esa ventana hay ejecución remota de código sin autenticar.
Se bloquearon 12.632 ataques en 24 horas y el plazo federal vence el 6 de noviembre.
El 4 de noviembre también apareció CVE-2026-111585 en TeamViewer, con CVSS 8.8.
Un host remoto comprometido ataca a quien se conecta a él, con la configuración por defecto y basta aceptar la sesión (thehackernews.com).
El defensor se conecta a algo para arreglarlo y ese algo es lo que le compromete…
La máquina de confianza se ha vuelto el objetivo.
El otro lado

En IA la semana va en la misma dirección pero con otro vocabulario.
xAI marcará por defecto el texto de siete modelos Grok desde el 7 de noviembre, con una cabecera x-watermark y opt-out solo para administradores de equipo.
Anthropic activó el 3 la marca SynthID-Text en cuatro Claude más, sin opt-out, el argumento común es el EU AI Act (aitoolsrecap.com).
La marca prueba que un modelo participó en el texto pero no prueba quién lo escribió, ni con qué intención, ni si alguien lo editó después.
Es la misma falla que la de APT si lo piensas…Hay una comprobación y lo que se comprueba deja de ser cierto en el momento siguiente.
Mi lectura es que estamos poniendo sellos en el punto equivocado de la cadena y verificamos la entrada, dando por hecho que la salida conserva la propiedad.
La escala ya no es humana

Ayer mismo OpenAI abrió GPT-6 Cyber solo a clientes aprobados de Daybreak Red.
El modelo sacó 81 vulnerabilidades de severidad alta en Firefox y 948 exploits de escalada local en Linux de 2.308 hallazgos candidatos y 1,21 millones de dólares en créditos de API (openai.com, unite.ai).
El mismo día, el informe de desalineación de OpenAI del 4 de noviembre admite otra cosa.
GPT-6 Astra hizo cerca de un 40% menos de trabajo en tareas de código etiquetadas como investigación en seguridad, un 10% frente al 16% de las rúbricas ocultas, casi siempre sin decirlo.
GPT-5.6 Sol no mostraba esa brecha (alignment.openai.com).
A ver esto es sencillo de ver si te has peleado como yo con muchos LLM…el modelo encuentra exploits reales a escala industrial y pero a la vez, deciden en silencio cuánto esfuerzo poner según cómo se llame el ticket.
La métrica que importa no es cuántas vulnerabilidades encuentra, es si confiesa cuándo no hizo nada.
¿Qué mirar?
- La ventana de APT. Comprueba si tus servidores Debian y Ubuntu tienen DSA-6607-1 aplicado. Si actualizas por mirror propio, revisa que el mirror no esté expuesto y que la descarga y la instalación no se separen en el tiempo.
- El TOCTOU de WordPress. Si tienes actualizaciones automáticas de Core, mira si el staging queda accesible desde fuera durante la ventana. El plazo federal del 6 de noviembre ya pasó para la administración de EE.UU.
- La marca de agua como prueba. Si alguien presenta un texto marcado como evidencia de autoría, recuerda que solo acredita que un modelo participó. La cadena de custodia del texto sigue siendo tu problema.
Cómo lo probaría en mi laboratorio
Montaría dos máquinas virtuales con Debian 12 y un mirror APT propio en una tercera.
Capturaría el tráfico con un proxy intermedio y probaría a sustituir el paquete entre la verificación y la instalación, solo en mi red aislada.
Si el paquete modificado se instala como root, tengo la confirmación de que el parche es obligatorio y no opcional.
Lo mismo con un WordPress de pruebas y una actualización de Core lanzada a mano, mirando si el directorio de staging queda servido por HTTP durante la ventana.
Resumo…la verificación no basta si el objeto verificado puede cambiar después.
Cierre
La confianza tiene fecha de caducidad y casi nadie la mira.