A severe security flaw in the LXD and Incus systems has been identified, allowing remote attackers to bypass login checks and seize control of clusters and managed virtual machines. This vulnerability is found in the HTTPS management listener, which risks exposing Linux systems without the need for a password, stolen private key, or user involvement. Incus has rated this flaw as critical, assigning it a CVSS score of 10.0, indicating its high severity.
The Incus security advisory, released on October 29, reveals that this bug has been present since the project's inception. Canonical's related LXD advisory, CVE-2026-112816, followed on October 30, describing the issue as an unauthenticated pathway to full cluster and virtual machine access, though they assign it a medium priority.
The flaw arises from improper certificate validation during HTTPS connections. While the TLS handshake confirms the client's possession of the private key for the first certificate in the chain, the remaining certificates, which are not verified, are controlled by the client. This flaw allows an attacker to append a trusted certificate's public part to their own chain and be mistakenly accepted as its owner.
Public certificates, which are accessible through TLS handshakes, can be exploited by attackers who do not require an account to obtain one. By presenting the server's own certificate, attackers can gain database gateway access, while using another cluster member's certificate grants internal cluster access, bypassing authorization completely.
Incus reports that attackers can impersonate trusted client, metrics, or server certificates if they have the relevant public certificate. The vulnerability also affects the authorization scriptlet used for access decisions and impacts connections using tokens or OpenID Connect. Versions before 7.6.0 are affected, and patches are available from version 7.6.0 onwards. Canonical advises updating to LXD versions 4.0.15, 5.0.11, 5.21.9, and 6.10.1.
Administrators should immediately update their systems and restrict HTTPS listener access to trusted hosts as a temporary measure. There is no configuration workaround for this validation error, and network restrictions are insufficient without patches. Although no active exploitation has been reported, this vulnerability underscores the importance of proactive security measures.
