There’s a class of security bug that ordinary tooling never sees. It isn’t a known pattern or a misused function. The code does exactly what it was written to do, and that’s the problem: it doesn’t match what the security model intended. A check is missing, and where there’s nothing to spot, static analysis stays silent. Canonical has now explained how it goes after that blind spot with Redhound, an internal AI auditing agent.
What Redhound is
Redhound was built by Miha Purg at Canonical in early 2026. The premise is to put frontier AI models to work reasoning about business-logic vulnerabilities: the domain-specific bugs that historically only a human security researcher would catch by reading the code and asking what’s absent.
The agent runs in five phases. It starts with deterministic recon, where static analysis maps functions, types, call edges, entry points and security signals. Then comes threat modeling, with an agent identifying attacker objectives and mapping trust boundaries. The third phase is an iterative loop: red-team agents generate attack hypotheses while investigator agents pursue or refute each one. The fourth is the safeguard that keeps false positives down. A separate agent independently searches for runtime guards that would prevent a confirmed finding. Last comes impact assessment, cross-referencing each finding against the threat model to confirm it’s actually exploitable.
What the human reviewer gets is a draft report and a runnable proof-of-concept exploit, not a vague alert.
Three zero-days in LXD
The real test came with LXD, Canonical’s container and virtual machine manager. Redhound found three critical vulnerabilities in LXD 6.7, all three scoring CVSS 3.1 of 9.1, in under a day of unsupervised analysis. Every one of them had survived years of manual review and static analysis tooling.
The first, CVE-2026-34179, is a certificate type escalation (CWE-915, mass assignment). A restricted certificate user could become cluster admin by changing the certificate type during an update. The system checked the original’s Restricted, Name and Projects fields, but the Type field went unchecked.
The second, CVE-2026-34177 (CWE-184, incomplete denylist), let a restricted project user reach host root by injecting arbitrary QEMU configuration. The raw.qemu.conf key wasn’t in a four-element blocklist, so it slipped through. An unlisted key is indistinguishable from one that was intentionally allowed.
The third, CVE-2026-34178 (CWE-20, improper input validation), exploited a desync during backup restore. The index.yaml held a clean config while the backup.yaml carried forbidden settings such as security.privileged and raw.lxc. Validation read index.yaml, but the import used backup.yaml.
Why it matters to you
None of the three comes from a recognizable error pattern. They’re missing checks, and an unlisted key looks exactly like a permitted one unless someone reads the code with that question in mind. An agent finding them in hours, after they sat hidden for years, signals a shift in how security software can be audited.
If you run Ubuntu or LXD in production, the practical point is that Canonical frames this as a recurring practice rather than a one-off audit. That’s the difference between catching three flaws once and reviewing the code systematically before anyone else gets there. We covered this and other security uses of AI in our piece on how Canonical applies AI to vulnerabilities.
For the rest of the system’s news, see the Ubuntu page.
Source
Based on Canonical’s original article on the Ubuntu blog: Finding the blind spot: How Canonical hunts logic flaws with AI. Authorship and data by Canonical.