External risk intelligence

LXD Privilege Escalation via Incomplete Denylist and AppArmor/QEMU Injection.

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-34177

LXD is a system container and virtual machine manager typically deployed on internal infrastructure or managed via internal APIs. While it can be network-accessible in specific cloud or multi-tenant environments, it is not designed to be a public-facing edge service. The vulnerability requires administrative permissions within a project, making public internet exposure and exploitation unlikely in common deployments.

Privilege Escalation

Canonical Lxd

4.12 to 5.0.65.21.0 to 5.21.46.0 to 6.7

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability in Canonical LXD software could allow a remote attacker with specific permissions to escalate privileges to cluster administrator and potentially gain host root access. This flaw stems from an incomplete denylist in the software's project restriction settings, which fails to block certain configurations that, when manipulated, can bridge the LXD Unix socket into a virtual machine.

Incomplete security checks in LXD software.
Could lead to administrator and host root access.
Confirm if LXD's restricted virtual machine features are in use.

Attack Path

How an attacker could exploit the issue

An attacker with edit permissions on a virtual machine within a restricted project could exploit a flawed access control list. This allows them to inject malicious configurations, specifically an AppArmor rule and a QEMU chardev setting, which effectively bridges the LXD Unix socket into the virtual machine. Successful exploitation grants the attacker elevated privileges, first to a cluster administrator and then to root access on the host system.

Requires edit permissions on VM.
Injects malicious configurations.
Results in host root access.

Live Threat

Current exploitation, exposure, and threat context

A remote attacker with specific permissions on a virtual machine within a restricted project could inject configurations that allow them to escape the VM's confines. This could lead to unauthorized access and control over the LXD system and its underlying host.

LXD system and host root access.
VM configuration injection.
Privilege escalation to host root.

Operational Fix

Recommended remediation, mitigation, and detection steps

This critical vulnerability in Canonical LXD affects systems where it's deployed, potentially impacting infrastructure, platform, and security teams. The first action should be to identify all LXD installations, determine their reachability and business criticality, and then assign ownership for remediation. Planning for updates or workarounds should be based on the assessed risk and potential impact on cluster administration and host root access.

Assign ownership to LXD administrators.
Verify affected LXD installations and reachability.
Plan risk-based remediation with vendor coordination.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Canonical LXD?

LXD is an open-source system container and virtual machine manager. It allows users to run complete Linux systems or isolated environments on a host machine. Developers and system administrators use it to manage virtualized resources, providing a way to package, deploy, and isolate applications and services across infrastructure, often used in cloud or multi-tenant environments.

What does CVE-2026-34177 mean by an incomplete denylist?

This vulnerability, classified as CWE-184 (Incomplete List of Disallowed Inputs), means the software's security controls failed to restrict all dangerous configuration options. Specifically, LXD meant to block certain low-level settings for virtual machines but left out specific AppArmor and QEMU configuration keys. This omission allows an attacker to bypass intended project restrictions.

How is this LXD vulnerability triggered?

An attacker needs 'can_edit' permissions on a virtual machine within a restricted project to trigger the flaw. Simply having access to the LXD system is not enough; the attacker must be able to modify VM settings. If the project restriction 'restricted.virtual-machines.lowlevel=block' is not active, or if the attacker lacks VM edit rights, this specific path cannot be used.

Is my system at risk according to Halo Surface Signal?

The risk is generally considered unlikely because LXD is typically deployed on internal infrastructure rather than as a public-facing edge service. Halo Surface Signal notes that since the vulnerability requires existing administrative permissions within a project, the barrier for exploitation is high, making it less likely to be exposed to random internet-based attacks.

What should I do if I run LXD?

First, perform an inventory to locate all active LXD installations and verify if they use restricted project features. Identify the administrators responsible for these clusters. Once mapped, coordinate with your team to review the vendor's security guidance and plan for software updates to address the missing denylist checks, prioritizing systems with higher business criticality.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.