Hi ha un tipus d’error de seguretat que les eines habituals no veuen. No és un patró conegut ni una funció mal feta servir: és codi que fa exactament el que es va escriure, però que no encaixa amb la intenció del model de seguretat. Falta una comprovació, i allà on no hi ha res a detectar, l’anàlisi estàtica es queda muda. Canonical acaba d’explicar com ataca aquest punt cec amb Redhound, un agent intern d’auditoria basat en IA.
Què és Redhound
Redhound el va desenvolupar Miha Purg dins de Canonical a principis del 2026. La idea és fer servir models d’IA de frontera per raonar sobre vulnerabilitats de lògica de negoci: aquests bugs específics de cada domini que històricament només trobava un investigador de seguretat amb experiència, llegint el codi i preguntant-se què hi falta.
L’agent treballa en cinc fases. Primer un reconeixement determinista, amb anàlisi estàtica que mapeja funcions, tipus, crides, punts d’entrada i senyals de seguretat. Després arriba el modelatge d’amenaces, on un altre agent identifica els objectius d’un atacant i traça els límits de confiança. La tercera fase és un bucle iteratiu: agents de red team generen hipòtesis d’atac i agents investigadors les persegueixen o les descarten. La quarta és la més rellevant per evitar falsos positius: un agent separat busca de manera independent guardes en temps d’execució que invalidarien una troballa. I per acabar, l’avaluació d’impacte creua cada troballa confirmada amb el model d’amenaces per verificar que sigui realment explotable.
El resultat per al revisor humà no és una alerta vaga, sinó un esborrany d’informe i una prova de concepte executable.
Tres zero-days a LXD
La prova real va arribar amb LXD, el gestor de contenidors i màquines virtuals de Canonical. Redhound va trobar tres vulnerabilitats crítiques a LXD 6.7, totes tres amb CVSS 3.1 de 9.1, en menys d’un dia d’anàlisi sense supervisió. I totes havien sobreviscut anys de revisió manual i d’eines d’anàlisi estàtica.
La primera, CVE-2026-34179, és una escalada de tipus de certificat (CWE-915, assignació massiva). Un usuari amb certificat restringit es podia convertir en administrador del clúster canviant el tipus de certificat durant una actualització: el sistema comprovava els camps Restricted, Name i Projects de l’original, però no el camp Type.
La segona, CVE-2026-34177 (CWE-184, llista de denegació incompleta), permetia a un usuari d’un projecte restringit aconseguir root a l’amfitrió injectant configuració arbitrària de QEMU. La clau raw.qemu.conf no figurava en una llista de bloqueig de quatre elements, de manera que passava el filtre.
La tercera, CVE-2026-34178 (CWE-20, validació d’entrada deficient), aprofitava una desincronització en restaurar còpies de seguretat: l’index.yaml contenia una configuració neta mentre que el backup.yaml incloïa ajustos prohibits com security.privileged i raw.lxc. La validació mirava l’index.yaml, però la importació feia servir el backup.yaml.
Per què t’importa
El que tenen en comú les tres és que cap no ve d’un patró d’error reconeixible. Són comprovacions que faltaven, i una clau no llistada és indistingible d’una permesa expressament si ningú llegeix el codi amb aquesta pregunta al cap. Que un agent les hagi trobat en hores, quan feia anys que estaven amagades, marca un canvi en com es pot auditar programari de seguretat.
Si fas servir Ubuntu o LXD en producció, el punt pràctic és que Canonical no ho planteja com una auditoria puntual, sinó com una pràctica recurrent. Aquesta és la diferència entre trobar tres errors una vegada i revisar el codi de manera sistemàtica abans que algú altre els trobi. En vam parlar, juntament amb altres usos de la IA en seguretat, al nostre repàs sobre com Canonical aplica la IA a les vulnerabilitats.
Pots veure la resta de novetats del sistema a la fitxa d’Ubuntu.
Font
Informació de l’article original de Canonical al blog d’Ubuntu: Finding the blind spot: How Canonical hunts logic flaws with AI. Autoria i dades de Canonical.