CVE-2026-112816 in LXD
Summary
by MITRE • 10/30/2026
Improper certificate validation in the HTTPS listener in Canonical LXD 4.0.14, 5.0.10, 5.21.8, 6.9 before 4.0.15, 5.0.11, 5.21.9, 6.10.1 allows an unauthenticated attacker to authenticate as any trusted client and gain full access to the cluster and managed virtual machines via a crafted certificate chain.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Canonical LXD versions prior to 4.0.15, 5.0.11, 5.21.9, and 6.10.1 represents a critical failure in the transport layer security implementation within the HTTPS listener component of the container management platform. This flaw stems from improper certificate validation logic during the mutual TLS authentication process. In a properly secured LXD deployment, clients connecting to the daemon must present valid certificates that are signed by a trusted Certificate Authority known to the server. The vulnerability arises because the application fails to rigorously validate the entire certificate chain presented by an unauthenticated attacker. Specifically, the implementation allows for the acceptance of crafted certificate chains that bypass standard trust anchor verification mechanisms. This deficiency effectively neutralizes the authentication barrier intended to protect access to the LXD daemon and its associated cluster resources.
From a technical perspective, this flaw aligns with CWE-295 Improper Certificate Validation, where software does not properly validate certificates or certificate paths against trusted anchors. The attacker exploits this by constructing a malicious certificate chain that appears valid within the context of the flawed validation logic. By leveraging this crafted input, an unauthenticated actor can successfully authenticate as any client whose identity is protected under the cluster's trust model. This capability allows the adversary to impersonate legitimate users or service accounts without possessing their private keys, thereby bypassing cryptographic authentication controls entirely. The attack vector relies on network-level access to the LXD API endpoint and does not require prior credentials, classifying it as an unauthenticated remote code execution risk at the application layer.
The operational impact of this vulnerability is severe due to the privileged nature of the LXD daemon. Once authenticated via the flawed certificate validation mechanism, the attacker gains full administrative control over the entire cluster environment. This includes the ability to manage virtual machines and containers, modify network configurations, access sensitive host filesystems through mount points, and execute arbitrary commands within the context of the root user on the underlying host system. Since LXD often runs with elevated privileges to facilitate container isolation features that rely on kernel capabilities, successful exploitation can lead to complete compromise of the infrastructure hosting the virtualized workloads. The attacker can escalate from container escape to full host takeover, potentially affecting all other tenants or services running on the same physical hardware if multi-tenancy is employed without strict security boundaries.
This vulnerability maps directly to MITRE ATT&CK technique T1078 Valid Accounts, specifically involving legitimate credentials obtained through improper validation rather than theft of actual secrets. It also relates to T1190 Exploit Public-Facing Application, as the HTTPS listener serves as a public-facing interface for management operations. The ability to authenticate as any trusted client effectively grants the attacker persistence and lateral movement capabilities within the cluster topology. They can create new administrative users, modify existing configurations to maintain access, or pivot to other nodes in the distributed storage network managed by LXD. The lack of proper chain validation means that even complex PKI setups are undermined if this specific code path is triggered with a malformed but syntactically acceptable certificate structure.
Mitigation requires immediate patching to the fixed versions listed above, which corrects the certificate parsing and verification routines in the HTTPS listener. Administrators should ensure that all LXD daemons within their clusters are updated simultaneously to prevent version skew attacks where an older node might be exploited as a foothold. In addition to applying patches, organizations should review their PKI infrastructure to enforce strict chain validation policies at the application level wherever possible. Network segmentation strategies can also help limit exposure by restricting access to LXD API endpoints only from trusted management networks using firewall rules or zero-trust network access controls. Regular auditing of certificate validity and expiration dates remains essential, although this specific flaw persists regardless of certificate age due to the fundamental logic error in validation rather than a trust anchor issue.