CVE-2026-34178
Received Received - Intake
Project Restriction Bypass in Canonical LXD Enables Host Compromise

Publication date: 2026-04-09

Last updated on: 2026-04-22

Assigner: Canonical Ltd.

Description
In Canonical LXD before 6.8, the backup import path validates project restrictions against backup/index.yaml in the supplied tar archive but creates the instance from backup/container/backup.yaml, a separate file in the same archive that is never checked against project restrictions. An authenticated remote attacker with instance-creation permission in a restricted project can craft a backup archive where backup.yaml carries restricted settings such as security.privileged=true or raw.lxc directives, bypassing all project restriction enforcement and allowing full host compromise.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-09
Last Modified
2026-04-22
Generated
2026-05-07
AI Q&A
2026-04-09
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 3 associated CPEs
Vendor Product Version / Range
canonical lxd From 4.12 (inc) to 5.0.6 (inc)
canonical lxd From 5.21.0 (inc) to 5.21.4 (inc)
canonical lxd From 6.0 (inc) to 6.7 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-20 The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-34178 is a critical vulnerability in Canonical LXD before version 6.8 that arises from inconsistent validation during the backup import process.

When importing a backup archive, LXD validates project restrictions against the file backup/index.yaml inside the archive. However, the actual instance is created using a different file, backup/container/backup.yaml, which is not checked against these restrictions.

An authenticated remote attacker with permission to create instances in a restricted project can craft a backup archive where backup.yaml contains restricted or privileged settings (such as security.privileged=true or raw.lxc directives). Because this file is not validated against project restrictions, the attacker can bypass all enforcement and create an instance with elevated privileges.

This flaw allows the attacker to escalate privileges and potentially compromise the entire host system.


How can this vulnerability impact me? :

This vulnerability can have severe impacts including full host compromise.

  • An attacker with standard instance-creation permissions in a restricted project can bypass project restrictions and create privileged containers.
  • The attacker can configure the container with privileged settings and raw.lxc directives that are normally blocked.
  • Once the container is started, the attacker can use bind-mounted LXD Unix sockets to gain administrative access to the LXD server.
  • This access allows the attacker to create admin certificates, access and modify any instance, and mount the host filesystem.
  • Overall, this leads to a complete compromise of the host system from within a restricted project.

What immediate steps should I take to mitigate this vulnerability?

To mitigate CVE-2026-34178, you should upgrade your LXD installation to a fixed version such as 5.0.7, 5.21.5, or 6.8 where the vulnerability has been addressed.

The fix involves ensuring that the actual instance configuration file (backup/container/backup.yaml) is validated against project restrictions before instance creation, preventing attackers from bypassing restrictions.

Interim releases and LTS updates have been issued by Canonical to address this vulnerability, so applying these updates promptly is critical.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

This vulnerability allows an authenticated attacker with instance-creation permissions in a restricted project to bypass project restrictions and gain full host compromise. Such a compromise can lead to unauthorized access to sensitive data and systems, which directly impacts the confidentiality, integrity, and availability of information.

Because of the potential for full host compromise and unauthorized administrative access, organizations using affected versions of Canonical LXD could face significant compliance risks with standards and regulations such as GDPR and HIPAA, which mandate strict controls on data access and system security.

Failure to mitigate this vulnerability could result in violations of these regulations due to unauthorized data exposure or manipulation, potentially leading to legal and financial penalties.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

Detection of CVE-2026-34178 involves identifying whether an attacker has imported a malicious backup archive that bypasses project restrictions by exploiting the unchecked backup.yaml configuration.

Since the vulnerability is related to the backup import process in Canonical LXD before version 6.8, detection can focus on monitoring backup import activities and inspecting backup archives for inconsistencies between backup/index.yaml and backup/container/backup.yaml.

Suggested commands and approaches include:

  • Manually inspect backup archives (tar files) before import by extracting and comparing the contents of backup/index.yaml and backup/container/backup.yaml to detect discrepancies or restricted settings such as security.privileged=true or raw.lxc directives.
  • Use tar commands to extract and view these files, for example:
  • tar -xf backup-archive.tar backup/index.yaml
  • tar -xf backup-archive.tar backup/container/backup.yaml
  • Check the LXD logs for instance creation events and verify if any instances were created with privileged or raw.lxc configurations despite project restrictions.
  • Monitor for unusual container configurations or unexpected privileged containers in restricted projects.

Automated detection tools or scripts could be developed to parse backup archives and validate that the configuration in backup/container/backup.yaml matches the restrictions enforced on backup/index.yaml, but no specific commands or tools are provided in the available resources.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart