Cyber Resilience

CVE-2026-34177

Canonical Lxd 4.12 – 5.0.6

Published
09 April 2026
Modified
22 April 2026
CVSS Score v3.1 9.1
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
EPSS Score 0.0036 29th percentile
Risk Priority 58 floored blend · peak EPSS

Summary

CVE-2026-34177 is a critical-severity Incomplete List of Disallowed Inputs (CWE-184) vulnerability in Canonical Lxd. Its CVSS base score is 9.1 (Critical).

Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked at the 29th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) — see the control section below for these in your framework.

Deeper analysis AI-assisted summary

Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.

Canonical LXD versions 4.12 through 6.7 are affected by CVE-2026-34177, an incomplete denylist vulnerability in the isVMLowLevelOptionForbidden function located in lxd/project/limits/permissions.go. This flaw fails to block the raw.apparmor and raw.qemu.conf keys under the restricted.virtual-machines.lowlevel=block project restriction, allowing unauthorized low-level configurations in virtual machines.

A remote attacker with can_edit permission on a VM instance within a restricted project can exploit this by injecting a custom AppArmor rule and QEMU chardev configuration. This bridges the LXD Unix socket into the guest VM, enabling privilege escalation to LXD cluster administrator and subsequently to host root privileges. The vulnerability has a CVSS v3.1 base score of 9.1 (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) and is associated with CWE-184 (Incomplete List of Disallowed Inputs).

Mitigation details are provided in the GitHub security advisory GHSA-fm2x-c5qw-4h6f and the associated pull request at github.com/canonical/lxd/pull/17909, which patches the denylist to include the missing raw.apparmor and raw.qemu.conf keys. Security practitioners should review these resources for upgrade instructions and apply the fix promptly to affected LXD deployments.

EU & UK References

Vulnerability Data

Canonical LXD versions 4.12 through 6.7 contain an incomplete denylist in isVMLowLevelOptionForbidden (lxd/project/limits/permissions.go), which 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…

more

a restricted project can 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.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1190 Exploit Public-Facing Application Initial Access
Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2026-28385Same product: Canonical Lxd
CVE-2025-54292Same product: Canonical Lxd
CVE-2025-54289Same product: Canonical Lxd
CVE-2026-12411Same product: Canonical Lxd
CVE-2026-34178Same product: Canonical Lxd
CVE-2026-34179Same product: Canonical Lxd
CVE-2026-9640Same product: Canonical Lxd
CVE-2024-6219Same product: Canonical Lxd
CVE-2025-54291Same product: Canonical Lxd
CVE-2024-6156Same product: Canonical Lxd

Affected Assets

canonical
lxd
4.12 — 5.0.6 · 5.21.0 — 5.21.4 · 6.0 — 6.7

Mitigating Controls

Control response

Prevent
Stop it (NIST 800-53)

Detect
Catch it (NIST detect / respond)

Harden
Shrink the surface (DISA STIG)
  • 2 hardening rules · 1 OS baseline
Validate
Prove the fix (OWASP ASVS)
  • V3.5.2
  • V4.4.2
  • V16.2.5

Mitigating Controls (NIST 800-53 r5) AI

SI-10 requires validity checks on inputs, which structurally replaces incomplete deny-lists with complete allow-list or sanitization logic.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly require complete, positive input validation instead of incomplete denylists.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

finds

Security testing can discover missing input checks, but does not prevent the weakness during development.

prevents

Application security requirements can mandate complete input validation rules, but the control itself does not prescribe how to build those rules.

prevents

Secure architecture principles include robust input validation design, yet the control is broader than this single weakness.

prevents

Secure coding standards directly require exhaustive allow-lists or complete deny-lists for inputs, addressing the root cause of incomplete disallowed-input lists.

References