Critical Incus and LXD Vulnerabilities Allow Unauthenticated Attackers to Gain Full Cluster Access

Critical certificate-validation vulnerabilities have been identified in Incus and Canonical LXD, allowing unauthenticated attackers to impersonate trusted identities and compromise management infrastructure.

Exploitation of these vulnerabilities requires network access to the HTTPS listener but does not require valid credentials or the private key for a trusted certificate. This LXD vulnerability may expose entire clusters and their managed virtual machines.

The Incus issue, tracked as GHSA-xg75-xf37-cph9, has a maximum CVSS score of 10.0. It affects all releases prior to version 7.6.0, and maintainers have indicated that this underlying behavior has existed since the initial release.

The advisory does not list any assigned CVE identifier and classifies the weakness under improper authentication and improper certificate validation.

Certificate Chain Validation Failure

According to Ubuntu, the vulnerability originates in how the HTTPS listener handles client certificates. Although it requests certificates during TLS negotiation, it does not verify the supplied chain.

The handshake establishes possession of the private key corresponding only to the first certificate, while the connecting client controls the subsequent certificates.

Authentication checks nevertheless compared every certificate in that chain against the trust store. An attacker could append a trusted identity’s public certificate to an attacker-controlled chain and authenticate without its private key.

The previously disclosed Teleport authentication bypass likewise illustrates the consequences of failed identity verification, although its mechanism differs.

Server certificates make exploitation particularly accessible because TLS handshakes disclose them publicly. Appending the target server’s certificate grants database gateway access, while presenting another cluster member’s certificate enables internal cluster access and bypasses authorization entirely. Trusted client and metrics certificates also become impersonation targets when their public certificates are available.

The weakness extends beyond initial authentication. Attackers can abuse self-service paths to renew or delete trust-store entries, and host-to-VM agent authentication is affected. Unverified certificates also reach authorization scriptlets, allowing attacker-selected certificate data to influence decisions even for token or OpenID Connect clients.

This authorization exposure echoes concerns raised by the separate HashiCorp Consul authorization bypass. However, the Incus advisory specifically identifies client-controlled certificate chains as the route to impersonate trusted identities and influence certificate-based authorization decisions.

Canonical tracks the LXD issue as CVE-2026-112816, published October 30, 2026. Its notice identifies affected versions 4.0.14, 5.0.10, 5.21.8, and 6.9, with fixes in 4.0.15, 5.0.11, 5.21.9, and 6.10.1, respectively. It describes unauthenticated access to clusters and managed virtual machines through crafted certificate chains.

The separate Red Hat Kubernetes cluster-proxy vulnerability also highlights cluster-management exposure, although it involves server-side request forgery rather than certificate-chain impersonation.

Administrators should upgrade Incus to 7.6.0 or later and deploy the appropriate patched LXD release. Until updates are installed, restrict HTTPS management access to trusted hosts. Incus maintainers state that no configuration-based workaround fixes the vulnerability, network restrictions reduce exposure but do not correct the underlying certificate-validation failure.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.