CVE-2026-34177: Canonical LXD Privilege Escalation Flaw

CVE-2026-34177 Overview

Canonical LXD versions 4.12 through 6.7 contain an incomplete denylist vulnerability in the isVMLowLevelOptionForbidden function located in lxd/project/limits/permissions.go. This security flaw omits raw.apparmor and raw.qemu.conf from the set of keys blocked under the restricted.virtual-machines.lowlevel=block project restriction. A remote attacker with can_edit permission on a VM instance in a restricted project can exploit this vulnerability to inject an AppArmor rule and a QEMU chardev configuration that bridges the LXD Unix socket into the guest VM, enabling privilege escalation to LXD cluster administrator and subsequently to host root.

Critical Impact

This vulnerability enables privilege escalation from a restricted VM user to full LXD cluster administrator and host root access, compromising the entire container infrastructure.

Affected Products

• Canonical LXD versions 4.12 through 6.7
• LXD deployments using restricted.virtual-machines.lowlevel=block project restrictions
• Multi-tenant LXD cluster environments with VM workloads

Discovery Timeline

• 2026-04-09 - CVE-2026-34177 published to NVD
• 2026-04-09 - Last updated in NVD database

Technical Details for CVE-2026-34177

Vulnerability Analysis

This vulnerability falls under CWE-184 (Incomplete List of Disallowed Inputs), representing a critical security bypass in LXD's VM isolation mechanisms. The isVMLowLevelOptionForbidden function maintains a denylist of configuration keys that restricted users cannot modify when the restricted.virtual-machines.lowlevel=block setting is enabled on a project. However, the implementation fails to include two critical keys: raw.apparmor and raw.qemu.conf.

The attack leverages the ability to specify custom AppArmor rules and QEMU configuration options to create a bridge between the guest VM and the host's LXD Unix socket. By injecting a QEMU chardev configuration, an attacker can expose the LXD control socket inside the guest VM, effectively bypassing all container isolation and gaining full control over the LXD cluster.

Root Cause

The root cause is an incomplete security control implementation in the denylist filtering mechanism. When designing the isVMLowLevelOptionForbidden function, the developers failed to enumerate all dangerous low-level configuration keys that could be abused to escape VM isolation. Specifically, the raw.apparmor key allows modification of the AppArmor security profile applied to the VM, while raw.qemu.conf permits injection of arbitrary QEMU configuration directives—both of which can be weaponized to break VM containment.

Attack Vector

The attack requires network access and elevated privileges (can_edit permission on a VM instance). The attacker must have legitimate access to a restricted LXD project with the restricted.virtual-machines.lowlevel=block setting enabled. The scope is changed, meaning successful exploitation impacts resources beyond the vulnerable component's security boundary—specifically allowing escape from VM isolation to host-level access.

The exploitation chain involves:

1. Identifying a VM instance in a restricted project where the attacker has can_edit permission
2. Modifying the VM configuration to inject a malicious raw.apparmor rule that permits access to the LXD Unix socket
3. Adding a raw.qemu.conf entry that creates a chardev mapping the host's LXD socket into the guest
4. Restarting the VM to apply the configuration changes
5. From within the guest VM, connecting to the exposed LXD socket to issue administrative commands
6. Escalating to LXD cluster administrator and subsequently to host root

For technical details on the exploitation mechanism, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-34177

Indicators of Compromise

• Unexpected modifications to raw.apparmor or raw.qemu.conf settings on VM instances in restricted projects
• VM configuration changes that reference the LXD Unix socket path (typically /var/lib/lxd/unix.socket or /var/snap/lxd/common/lxd/unix.socket)
• Unusual chardev entries in QEMU process arguments containing socket mappings
• LXD API activity originating from within guest VM network namespaces

Detection Strategies

• Monitor LXD configuration change events for raw.apparmor and raw.qemu.conf keys using lxc monitor or the LXD events API
• Implement audit logging on LXD Unix socket access to detect unauthorized connections
• Review QEMU process command lines for unexpected chardev configurations bridging host resources
• Deploy file integrity monitoring on AppArmor profile directories to detect unauthorized modifications

Monitoring Recommendations

• Enable verbose logging in LXD to capture all configuration modification requests
• Set up alerts for any VM configuration changes involving raw.* keys in restricted projects
• Monitor for privilege escalation patterns such as users gaining cluster-admin permissions unexpectedly
• Audit LXD API access logs for unusual patterns or authentication from unexpected sources

How to Mitigate CVE-2026-34177

Immediate Actions Required

• Upgrade LXD to a patched version that properly blocks raw.apparmor and raw.qemu.conf under the restricted.virtual-machines.lowlevel=block restriction
• Review all VM configurations in restricted projects for unauthorized raw.apparmor or raw.qemu.conf entries
• Audit user permissions to ensure can_edit access is granted only to trusted users
• Consider temporarily disabling VM creation in restricted projects until patches are applied

Patch Information

Canonical has addressed this vulnerability through a code fix that adds raw.apparmor and raw.qemu.conf to the denylist in the isVMLowLevelOptionForbidden function. The fix is available in the GitHub Pull Request #17909. Users should upgrade to the latest patched version of LXD that includes this fix.

For detailed information about the vulnerability and remediation, consult the GitHub Security Advisory GHSA-fm2x-c5qw-4h6f.

Workarounds

• Revoke can_edit permissions from untrusted users on VM instances in restricted projects until the patch is applied
• Manually inspect and remove any suspicious raw.apparmor or raw.qemu.conf entries from existing VM configurations
• Implement network-level controls to restrict access to the LXD API from untrusted networks
• Consider using container instances instead of VMs in restricted projects where the stricter isolation of patched VMs is not yet available

# Check for potentially malicious VM configurations
lxc config show <vm-name> | grep -E "raw\.(apparmor|qemu\.conf)"

# List all VMs in a project and check their configurations
lxc list --project <project-name> --format csv -c n | xargs -I {} lxc config show {} --project <project-name> | grep -E "raw\.(apparmor|qemu\.conf)"

# Remove suspicious configuration entries
lxc config unset <vm-name> raw.apparmor
lxc config unset <vm-name> raw.qemu.conf