External risk intelligence

Canonical LXD Backup Import Restriction Bypass Leading to Host Compromise

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-34178

LXD is a system container manager typically deployed on internal infrastructure or isolated server environments. While it can be networked, it is generally managed by authorized administrators rather than exposed directly to the public internet, making widespread public internet exposure uncommon.

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 allows an authenticated remote attacker to bypass project restrictions and potentially compromise the host system. This occurs when a specially crafted backup archive is imported, enabling the execution of restricted settings.

An import flaw allows bypassing security controls.
Matters if LXD manages sensitive internal systems.
Confirm relevance and exposure of LXD systems.

Attack Path

How an attacker could exploit the issue

An attacker with instance-creation privileges in a restricted project can craft a special backup archive. This archive tricks LXD into applying settings from a less-restricted file within the archive, bypassing project security controls and potentially allowing full control over the host system.

Authenticated attacker needed.
Import malicious backup archive.
Full host compromise possible.

Live Threat

Current exploitation, exposure, and threat context

An authenticated attacker with instance-creation privileges in a restricted project could craft a malicious backup archive. This archive could contain a specially crafted `backup.yaml` file, bypassing project restrictions and potentially allowing for full host compromise when imported.

Host system compromise.
Malicious archive import.
Unauthorized host access.

Operational Fix

Recommended remediation, mitigation, and detection steps

The Canonical LXD platform's backup import functionality is implicated in this critical vulnerability. Teams responsible for LXD deployments, including infrastructure or platform engineers, should lead the initial triage. The immediate priority is to inventory all LXD instances, confirm exposure, identify business criticality, and pinpoint the accountable owner for each instance before planning remediation.

Own the LXD deployment and remediation.
Verify LXD instance exposure and criticality.
Plan remediation considering business impact.

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?

Canonical LXD is a system container manager used to run and manage full Linux systems in isolated containers. It provides a way to deploy and maintain multiple secure environments on a single host. In cloud and infrastructure setups, it is often utilized to isolate workloads, allowing administrators to apply specific project-level restrictions to control what those containers can do.

How does CVE-2026-34178 bypass security controls?

This vulnerability is an instance of Improper Input Validation (CWE-20). When importing a backup archive, LXD checks security restrictions against one file, but then creates the instance using a different file inside the same archive. An attacker can place restricted settings in this second file, which LXD fails to validate, effectively tricking the system into applying configurations that should have been blocked.

What must an attacker do to trigger this flaw?

An attacker must already have instance-creation permissions within a restricted project to initiate the backup import. Simply accessing the LXD management interface is not enough to trigger the bug. The attack requires uploading a specially crafted backup archive where the internal configuration files are manipulated to bypass project-level enforcement.

Is my LXD system at risk from this vulnerability?

Per Halo Surface Signal, LXD is typically deployed on internal infrastructure or isolated server environments, making public internet exposure rare. However, if your LXD instances are reachable by users who have, or could gain, instance-creation privileges, you should assess the risk. Focus on environments where you allow multiple users or external processes to manage their own container backups.

How should I respond to this threat advisory?

Start by identifying all LXD instances running in your environment to understand your total footprint. Prioritize these based on their business criticality and who has administrative access. Confirm the current software version to see if it falls within the affected ranges, and coordinate with your infrastructure team to plan for updates as the primary path to securing your deployments.

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.