External risk intelligence

LXD Instance Migration Bypass Allows Project Restriction Evasion

CVE advisorySeverity: CRITICAL (CVSS 9.9)

CVE-2026-63300

LXD is typically deployed in secured internal infrastructure or developer environments. Exploitation requires authenticated access with specific 'can_create_instances' permissions within a project, significantly limiting exposure to authorized internal users rather than the general public internet.

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

This vulnerability in LXD allows an authenticated user with specific permissions to bypass project-level security settings during instance migration. It could potentially enable unauthorized access to restricted system configurations or functionalities. The primary concern is confirming if your LXD environment is affected and understanding the potential exposure.

Bypasses security rules during instance moves.
Matters for preventing unauthorized privilege escalation.
Confirm relevance and exposure to LXD usage.

Attack Path

How an attacker could exploit the issue

An attacker with the ability to create instances and migrate them can bypass project-level security restrictions. This is achieved by migrating an instance into a restricted project without proper validation of its configuration against the target project's security policies. The vulnerability occurs during the instance migration process when LXD fails to check the instance's settings against enforced restrictions.

Authenticated user with creation permissions.
Migrating an instance between projects.
Bypass security restrictions and gain privileges.

Live Threat

Current exploitation, exposure, and threat context

An authenticated attacker with specific permissions could bypass project security restrictions when migrating LXD instances. This may allow an instance to inherit or gain access to restricted system configurations, user data, or service behaviors that should be disallowed within the target project.

Restricted instance configurations.
Migration bypasses project restrictions.
Could allow unauthorized access.

Operational Fix

Recommended remediation, mitigation, and detection steps

To address this vulnerability, application owners and platform teams are likely responsible for identifying and mitigating the risk. The first practical step involves locating all instances of LXD, determining their reachability and business criticality, identifying the accountable owner for each instance, and then planning remediation based on the assessed risk.

Ownership: Application and platform teams.
Verify first: Identify and assess LXD instances.
Action: Plan and coordinate remediation.

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 how is it used?

LXD is a next-generation system container and virtual machine manager. It provides a way to run and manage full Linux systems or isolated environments on a host machine, often used by developers and cloud administrators to create, deploy, and scale infrastructure instances efficiently.

What is the vulnerability in CVE-2026-63300?

This vulnerability is an instance of Improper Authorization, classified as CWE-862. It means the software fails to perform necessary permission checks during a specific action—in this case, migrating an instance between projects—allowing a user to perform an action they are not authorized to complete.

How does an attacker trigger this security bypass?

An attacker must already have 'can_create_instances' permissions. The bypass occurs specifically during the instance migration process. It does not trigger if the instance is simply created or managed within a single project; the security check failure only happens when moving a specially crafted instance from an unrestricted project into a restricted one.

Is my LXD environment at high risk?

According to Halo Surface Signal, this is unlikely for most users because LXD is generally deployed in secured internal environments. Because the vulnerability requires existing authenticated access and specific project permissions, it is much more of an internal risk than a broad, internet-facing threat.

What should I do to secure my LXD instances?

Start by identifying all your active LXD deployments and determining which teams own them. Assess which projects handle sensitive or restricted configurations. Once you have an inventory of your environment, coordinate with your platform team to review the advisory and plan the necessary software updates to ensure migration checks are properly enforced.

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.