Hay un tipo de fallo de seguridad que las herramientas habituales no ven. No es un patrón conocido ni una función mal usada: es código que hace exactamente lo que se escribió, pero que no encaja con la intención del modelo de seguridad. Falta una comprobación, y donde no hay nada que detectar, el análisis estático se queda mudo. Canonical acaba de contar cómo está atacando precisamente ese punto ciego con Redhound, un agente interno de auditoría basado en IA.
Qué es Redhound
Redhound lo desarrolló Miha Purg dentro de Canonical a principios de 2026. La idea es usar modelos de IA de frontera para razonar sobre vulnerabilidades de lógica de negocio: esos bugs específicos de cada dominio que históricamente solo encontraba un investigador de seguridad con experiencia, leyendo el código y preguntándose qué falta.
El agente trabaja en cinco fases. Primero un reconocimiento determinista, con análisis estático que mapea funciones, tipos, llamadas, puntos de entrada y señales de seguridad. Después llega el modelado de amenazas, donde otro agente identifica los objetivos de un atacante y traza los límites de confianza. La tercera fase es un bucle iterativo: agentes de red team generan hipótesis de ataque y agentes investigadores las persiguen o las descartan. La cuarta es la más interesante para evitar falsos positivos: un agente separado busca de forma independiente guardas en tiempo de ejecución que invalidarían un hallazgo. Y por último, la evaluación de impacto cruza cada hallazgo confirmado contra el modelo de amenazas para verificar que sea realmente explotable.
El resultado para el revisor humano no es una alerta vaga, sino un borrador de informe y una prueba de concepto ejecutable.
Tres zero-days en LXD
La prueba real llegó con LXD, el gestor de contenedores y máquinas virtuales de Canonical. Redhound encontró tres vulnerabilidades críticas en LXD 6.7, las tres con CVSS 3.1 de 9.1, en menos de un día de análisis sin supervisión. Y todas habían sobrevivido años de revisión manual y de herramientas de análisis estático.
La primera, CVE-2026-34179, es una escalada de tipo de certificado (CWE-915, asignación masiva). Un usuario con certificado restringido podía convertirse en administrador del clúster cambiando el tipo de certificado durante una actualización: el sistema comprobaba los campos Restricted, Name y Projects del original, pero no el campo Type.
La segunda, CVE-2026-34177 (CWE-184, lista de denegación incompleta), permitía a un usuario de un proyecto restringido conseguir root en el host inyectando configuración arbitraria de QEMU. La clave raw.qemu.conf no figuraba en una lista de bloqueo de cuatro elementos, así que pasaba el filtro.
La tercera, CVE-2026-34178 (CWE-20, validación de entrada deficiente), aprovechaba una desincronización al restaurar copias de seguridad: el index.yaml contenía una configuración limpia mientras que el backup.yaml incluía ajustes prohibidos como security.privileged y raw.lxc. La validación miraba el index.yaml, pero la importación usaba el backup.yaml.
Por qué te importa
Lo común a las tres es que ninguna se debe a un patrón de error reconocible. Son comprobaciones que faltaban, y una clave no listada es indistinguible de una permitida a propósito si nadie lee el código con esa pregunta en mente. Que un agente las haya encontrado en horas, cuando llevaban años ocultas, marca un cambio en cómo se puede auditar software de seguridad.
Si usas Ubuntu o LXD en producción, lo práctico es que Canonical no lo plantea como una auditoría puntual, sino como una práctica recurrente. Esa es la diferencia entre encontrar tres fallos una vez y revisar el código de forma sistemática antes de que alguien más los encuentre. Hablamos de esto y de otros usos de la IA en seguridad en nuestro repaso sobre cómo Canonical aplica la IA a las vulnerabilidades.
Puedes ver el resto de novedades del sistema en la ficha de Ubuntu.
Fuente
Información del artículo original de Canonical en el blog de Ubuntu: Finding the blind spot: How Canonical hunts logic flaws with AI. Autoría y datos de Canonical.