CVE-2026-112816: Critical LXD Authentication Bypass

Are You Affected?

CVE-2026-112816 affects specific Canonical LXD releases whose HTTPS listener improperly validates client certificates and certificate chains. The NVD description identifies LXD 4.0.14, 5.0.10, 5.21.8, and 6.9 as vulnerable. The corresponding fixed releases are LXD 4.0.15, 5.0.11, 5.21.9, and 6.10.1.

The affected versions and fixes are:

The NVD record identifies those exact versions rather than a broad, open-ended range. Administrators should still verify the installed package or snap revision and confirm the vendor advisory for deployments using downstream packaging, custom builds, or distributions that backport security fixes.

A system is particularly exposed if its LXD HTTPS listener is reachable from the internet, untrusted internal networks, tenant networks, or systems outside the intended administrative boundary. Because the stated attack path does not require prior authentication, network reachability is the key initial exposure condition.

Analyst’s Take: Treat reachability as the first triage question, not the current absence of a CISA KEV listing or public PoC. A reachable listener on an affected version combines network access with no required credentials, so exposure review and patching should proceed in parallel.

Organizations reviewing broader identity controls may also benefit from understanding the distinction between OAuth and OpenID Connect in our OAuth vs. OpenID Connect FAQ.

The Fix, If You’re in a Hurry

Upgrade each LXD installation to the fixed release for its branch:

• LXD 4.0.14 → 4.0.15
• LXD 5.0.10 → 5.0.11
• LXD 5.21.8 → 5.21.9
• LXD 6.9 → 6.10.1

Use your organization’s approved package or snap-management process. Before changing production nodes, verify cluster health, backups, maintenance requirements, and compatibility with the installed operating system.

A version string alone may not identify a distribution backport. Consult the package changelog or vendor security metadata when the host is managed by an operating-system repository.

Technical Notes: Upgrade and interim mitigation

For snap-based installations, first inspect the installed LXD channel and revision:

sudo snap list lxd
sudo snap info lxd

Then refresh the snap using the organization’s approved channel. The exact channel should match the release branch in use; do not switch production systems between branches without a change review:

sudo snap refresh lxd
sudo snap list lxd
lxc version

For package-managed installations, use the operating system’s normal update mechanism and then verify the resulting version:

sudo apt update
sudo apt install --only-upgrade lxd
lxc version

The appropriate command can differ by distribution and packaging model. If the fixed version is not yet available through the local repository, do not assume that an ordinary update completed the remediation. Confirm the installed version against the fixed releases above or against the distribution’s security advisory.

Until patching is complete:

• Restrict access to the LXD HTTPS listener to trusted administration networks.
• Use firewall or security-group controls to permit only known management addresses.
• Remove public exposure.
• Review certificate trust configuration.
• Monitor authentication and administrative activity.

These measures reduce attack surface but do not correct the validation defect. If the LXD host is used to operate internet-facing services, consider layered endpoint and malware protection such as Get Bitdefender → as part of a broader defense-in-depth program. It is not a substitute for applying the LXD patch.

How This Vulnerability Works

CVE-2026-112816 is an improper certificate-validation vulnerability in LXD’s HTTPS listener. LXD uses certificate-based client authentication in deployments that trust client certificates. The vulnerable listener does not correctly validate a crafted certificate chain, allowing an unauthenticated attacker to present certificate material that is accepted as belonging to an arbitrary trusted client.

The practical security failure is an authentication-boundary bypass. Instead of proving possession of a legitimately issued and trusted client certificate, an attacker can exploit the listener’s certificate-chain handling to be authenticated as a trusted identity.

The supplied NVD description does not disclose the precise malformed-chain construction, validation branch, or affected code path. Defenders should therefore not infer that a particular certificate format or chain topology is the only exploitable condition.

After successful authentication, the attacker may gain access to the LXD API as a trusted client. The stated impact includes full cluster access and access to managed virtual machines. Exact operations can depend on cluster configuration, authorization controls, network topology, and the privileges associated with the accepted identity. Nevertheless, the vulnerability should be treated as a potential administrative compromise.

Technical Notes: Trust-boundary implications

The flaw is not described as a vulnerability in a single VM guest. It affects the LXD control plane and can cross the boundary between the LXD API, cluster management, and managed instances. Consequently, a compromise may require investigation beyond the host running the listener.

The supplied research does not provide exploit code, a certificate-chain recipe, or a protocol-level request example. Avoid relying on a narrow detection rule for one known proof of concept. Detection should instead combine listener access logs, certificate-authentication events, source-address analysis, and subsequent LXD administrative activity.

For background on denial-of-service terminology that may appear in incident reports, see our DoS glossary entry.

Severity, Explained

NVD assigns CVE-2026-112816 a CVSS base score of 10.0, classified as Critical. The score reflects the combination of remote network reachability, lack of required authentication, and severe confidentiality, integrity, and availability consequences implied by full cluster and managed-VM access.

The retrieved research note does not include the complete CVSS vector string. Therefore, the precise component-by-component vector should be obtained from the complete NVD JSON record before using it in automated scoring or compliance systems.

The available description establishes the important operational factors:

• An attacker can reach the HTTPS listener over a network.
• The attacker does not need valid credentials.
• The attacker may obtain control over highly privileged infrastructure.

A CVSS score is a prioritization input, not a forecast of exploitation. The absence of a CISA KEV listing does not reduce the technical severity. Internet exposure, cluster criticality, backup architecture, tenant isolation, and the ability to rotate trusted certificates should influence the remediation deadline.

Is It Being Exploited?

No confirmed exploitation in the wild was identified in the retrieved NVD and CISA KEV responses. The CVE was not present in the CISA Known Exploited Vulnerabilities catalog at the time of lookup, so it has no CISA date-added value, federal remediation deadline, required-action entry, or ransomware-campaign flag.

No relevant public proof of concept was identified in the sources supplied for this assessment. That status can change quickly after publication, particularly for a vulnerability with a CVSS 10.0 rating and an unauthenticated attack path.

Organizations should monitor Canonical advisories, NVD updates, threat-intelligence feeds, and internal telemetry rather than treating the current absence of a PoC as a safety guarantee.

The operational response is urgent remediation without claiming confirmed exploitation. A vulnerable, reachable LXD listener should be considered high risk even if there is no known campaign. If the listener was exposed to untrusted networks, investigate for unauthorized certificate authentication and administrative activity before and during the patch window.