A Decade-Old Bug With a Perfect Severity Score

A critical certificate validation flaw affecting LXD and Incus — two prominent platforms for managing Linux containers and virtual machines — could allow a remote attacker to bypass authentication entirely and seize control of a cluster and the workloads running on it. Incus, which forked from LXD, rates its version of the bug at a maximum CVSS score of 10.0. Canonical’s corresponding LXD advisory, tracked as CVE-2026-112816, describes an unauthenticated path to full cluster and virtual machine access, even though Ubuntu’s own classification lists it as only Medium severity.

According to the Incus security advisory published October 29, the flaw has existed since the project’s very first release — meaning it has been present, unnoticed, for the platform’s entire lifetime. Canonical’s related record for LXD followed on October 30.

The Problem: Validating the Wrong Thing

At the heart of the bug is a basic mismatch between what a TLS handshake actually proves and what LXD and Incus assumed it proved. During a standard HTTPS handshake, a client proves it holds the private key corresponding to the first certificate it presents — but any additional certificates included later in that chain are entirely under the client’s control and were never independently verified.

The authentication logic in LXD and Incus, however, checked every certificate in the submitted chain against the server’s trust store, not just the one whose ownership had actually been proven. That gap between “proving you hold a key” and “being trusted as a particular identity” is exactly what an attacker can exploit: by appending the public portion of a trusted certificate to their own certificate chain, an attacker can be accepted as that certificate’s legitimate owner — without ever possessing its private key.

Crucially, public certificates are not secret. Servers hand them out freely during ordinary TLS handshakes, which means an attacker doesn’t need an existing account or any prior access to obtain the certificates needed to carry out this trick. The advisory notes that presenting the server’s own certificate back to it grants access to its internal database gateway, while presenting another cluster member’s certificate grants internal cluster access and sidesteps authorization checks altogether.

Beyond Login: Trust Stores, Agents, and Access Scripts

This is a different category of problem than the container-escape vulnerabilities previously reported in tools like runc, which focus on breaking out of an isolated workload. This flaw instead undermines the management layer that is supposed to control who gets into the environment in the first place.

The exposure extends further than simple login bypass. According to the Incus advisory, an attacker able to present the right public certificate can impersonate trusted client, metrics, or server identities; renew or delete entries in the trust store via self-service mechanisms; and compromise the authentication used for agent connections between host systems and the virtual machines they manage.

The bug also reaches into the “authorization scriptlet” — a customizable script some deployments use to make fine-grained access decisions. Because Incus passed the full, unverified certificate chain into this script, an attacker’s forged certificates could directly influence those access decisions. Deployments using token-based or OpenID Connect authentication aren’t automatically safe either, since clients using those methods can still present certificates during the handshake and trigger the same flawed check.

Fixes and Interim Mitigations

Incus lists all versions prior to 7.6.0 as vulnerable, with 7.6.0 and later containing the fix. Canonical’s LXD advisory identifies patched releases at 4.0.15, 5.0.11, 5.21.9, and 6.10.1 across its respective release branches. Administrators should check their specific deployment against the relevant vendor advisory to confirm which branch and patch level applies.

Until an update can be applied, Incus recommends restricting access to the HTTPS management listener to trusted hosts only. Critically, there is no configuration change that fully resolves the underlying validation flaw — network-level restrictions reduce the attack surface but do not substitute for patching.

• Identify every LXD and Incus deployment in your environment and check its version against the fixed releases above.
• Apply vendor patches as a priority, treating internet-reachable management interfaces as especially urgent.
• Restrict network access to HTTPS listeners to known, trusted hosts in the interim.
• Review cluster membership and trust store entries for anything unexpected once patched.

Neither vendor advisory reports evidence of active exploitation at this time, but given the maximum severity rating and the fact that the flaw requires no password, stolen key, or user interaction, exposed management interfaces should be treated as a priority patching target.