External risk intelligence

LXD Authorization Bypass via TOCTOU Flaw in Configuration Merging Allows Project Restriction Bypass.

CVE advisorySeverity: CRITICAL (CVSS 9.9)

CVE-2026-63297

LXD is a system container manager typically restricted to internal infrastructure management, administrative, or developer environments. While it may be network-reachable in some specific deployments, it is generally not designed to be exposed directly to the public internet, and access is typically protected by internal network controls or authentication requirements.

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 critical vulnerability has been identified in LXD, a system container manager, due to a timing flaw in how it merges configurations. This flaw could allow an authenticated attacker to bypass project restrictions, potentially copying sensitive or privileged configurations into unintended environments. The main concern is confirming if this technology is in use and exposed.

Bypasses security controls on system container copies.
Matters for unauthorized privilege escalation risks.
Confirm relevance and exposure to avoid risks.

Attack Path

How an attacker could exploit the issue

An attacker with existing access can leverage a timing flaw in LXD's configuration merging process to bypass project restrictions. By initiating a cross-project instance copy, the attacker can exploit a window between the restriction check and the completion of configuration merging to introduce high-privilege settings into restricted projects, effectively circumventing security controls.

Requires authenticated access.
Exploits a timing flaw during copy.
Allows unauthorized privilege escalation.

Live Threat

Current exploitation, exposure, and threat context

An authenticated attacker could bypass project restrictions when copying LXD instances, allowing them to inject high-privilege configurations into restricted projects. This is possible due to a timing flaw where security checks occur before configuration merging is fully complete.

Instance configurations could be exposed.
Bypassing project restrictions during copies.
Unauthorized privileged configurations may be applied.

Operational Fix

Recommended remediation, mitigation, and detection steps

The LXD authorization bypass vulnerability requires immediate attention from teams managing the underlying infrastructure and security controls. The first practical step is to inventory all LXD deployments, identify which are network-reachable, and confirm their business criticality. Once identified, the accountable owner for each LXD instance must be determined to plan a coordinated remediation strategy based on the assessed risk.

Identify LXD owners and their environments.
Verify network reachability and criticality.
Plan remediation based on risk.

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 LXD and what is it used for?

LXD is a system container manager that provides a lightweight alternative to virtual machines. It allows developers and administrators to manage multiple isolated Linux systems—or containers—on a single host. It is widely used in infrastructure management and development environments to quickly deploy and scale application workloads while sharing the host's operating system kernel for efficiency.

What is the vulnerability behind CVE-2026-63297?

This vulnerability is an authorization bypass involving a time-of-check to time-of-use (TOCTOU) condition. In software, this happens when a program checks a security permission but the state changes before the action completes. In this case, LXD verifies project restrictions before finishing a configuration merge during an instance copy, allowing high-privilege settings to be applied where they should be blocked.

How does an attacker trigger this LXD flaw?

An attacker must already have authenticated access to the LXD environment to trigger the flaw. The issue specifically occurs during a cross-project instance copy operation. Importantly, simply running LXD or having read-only access does not trigger the bug; the attacker must be capable of initiating the copy process to exploit the specific timing window between the security check and the final configuration update.

Is my LXD deployment at risk?

According to Halo Surface Signal, risk depends heavily on your network architecture. LXD is typically intended for internal infrastructure or developer environments and is not meant for direct public internet exposure. If your LXD instance is isolated behind internal network controls, the likelihood of an attacker successfully reaching the service to initiate this copy operation is considered low.

What steps should I take if I use LXD?

Your first step is to perform an inventory to locate all LXD deployments within your environment. Once identified, categorize these instances by their network reachability and business criticality. Coordinate with the designated owners of these systems to verify the current configuration, assess the potential impact of an authorization bypass, and prepare a plan to apply necessary security updates.

References

github.com/canonical/lxd/security/advisories/GHSA-v989-qw7w-xvg4

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.