External risk intelligence

LXD authorization bypass allows exceeding project resource limits.

CVE advisorySeverity: CRITICAL (CVSS 9.9)

CVE-2026-63299

LXD is a system container manager typically deployed in internal infrastructure or private cloud environments. While network-reachable within a local administrative context, it is not designed to be exposed directly to the public internet, and access is usually restricted to authenticated internal users or administrators.

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 security flaw has been identified in LXD, a system container manager. This vulnerability allows authenticated users to bypass project-level resource limits, potentially leading to the unauthorized allocation of storage resources beyond administrative configurations. The primary concern is confirming the relevance and exposure of this issue within our specific LXD deployments.

Unauthorized storage use bypasses limits.
Confirms relevance and exposure in LXD.
Assess impact on resource governance.

Attack Path

How an attacker could exploit the issue

An authenticated user could exploit this vulnerability by manipulating disk and volume operations within LXD. By leveraging specific code paths that incorrectly handle resource limits, an attacker can bypass project-wide storage restrictions. This allows for the allocation of more storage than is permitted, potentially leading to denial of service or resource exhaustion.

Requires authenticated user access.
Triggered by volume move or snapshot restore.
Bypasses storage limits for projects.

Live Threat

Current exploitation, exposure, and threat context

An authenticated user could bypass project-level disk and volume limits in LXD, potentially leading to excessive storage resource allocation. This could occur when moving volumes across projects or during snapshot restore operations when certain configurations are not properly checked.

Storage resources.
Bypassing resource limit checks.
Exceeding configured limits.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability impacts LXD, a system container manager often deployed internally. Responsibility for addressing this likely falls to infrastructure or platform teams managing LXD, in coordination with security teams for exposure assessment. The first practical step is to locate all LXD instances, determine their reachability and criticality, identify the accountable owner, and then plan remediation based on the identified risk.

Infrastructure and platform teams own this.
Verify LXD instance reachability and criticality.
Plan remediation based on risk assessment.

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 system container manager used to run and manage full Linux systems in lightweight containers. It is widely employed by infrastructure teams to create private clouds, manage virtualized environments, and handle complex storage configurations. Because it serves as a foundational platform for deploying and scaling applications, it manages critical resources like disk space and storage volumes across different project environments.

What does CVE-2026-63299 mean for storage security?

This vulnerability is classified as CWE-770, which involves software allowing a user to consume more resources than intended. In this case, an authorization bypass means LXD fails to enforce project-level storage quotas. Essentially, the software overlooks pre-set limits, enabling users to claim excessive disk space or volume capacity that the system administrator specifically restricted to prevent abuse or service disruptions.

How can an attacker trigger this vulnerability?

An attacker needs existing authenticated access to an LXD instance to trigger these flaws. The issue occurs during specific administrative actions, specifically when moving a storage volume between projects or restoring a volume from a snapshot where certain configuration checks are skipped. Note that this cannot be triggered by simply accessing or browsing the system; it requires performing these specific volume management operations.

Should I worry if my LXD instance is internal?

According to Halo Surface Signal, LXD is typically deployed in private, internal infrastructure and is not meant to be directly internet-facing. While being internal reduces the risk of external discovery, you should still evaluate the vulnerability because it allows authenticated users—who might have limited permissions—to perform actions they are strictly forbidden from doing, potentially exhausting resources that other projects rely on.

How do I respond to this LXD advisory?

Start by identifying all LXD instances running within your environment to understand your footprint. Once mapped, assess which projects or teams manage these instances. Since this requires platform-level changes, coordinate with your infrastructure team to review the current configuration of storage volumes and project limits. Prioritize updating the software or applying patches provided by the maintainers as soon as they are made available to restore proper authorization enforcement.

References

github.com/canonical/lxd/security/advisories/GHSA-5h78-p252-989h

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.