What is the CVSS score of CVE-2026-63295?

CVE-2026-63295 has a CVSS 3.1 base score of 4.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L. EPSS exploitation probability: 0.2%.

Is there a patch available for CVE-2026-63295?

Yes, a patch is available for CVE-2026-63295. Update the affected software to the latest version immediately.

Canonical LXD CVE-2026-63295

EUVD-2026-57516 MEDIUM

Incorrect Authorization (CWE-863)

2026-08-12 canonical

Authentication Bypass Canonical Lxd

4.3

CVSS 3.1 · Vendor: canonical

Severity by source

Vendor (canonical) PRIMARY

4.3 MEDIUM

AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

vuln.today AI

4.3 MEDIUM

Bypass enables unauthorized privileged container state (I:L); no confidentiality or availability impact described; authenticated project member required (PR:L).

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

SUSE

MEDIUM

qualitative

Primary rating from Vendor (canonical).

CVSS VectorVendor: canonical

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

Low

Lifecycle Timeline

Patch available

Aug 12, 2026 - 21:17 EUVD

Analysis Generated

Aug 12, 2026 - 20:52 vuln.today

DescriptionCVE.org

An authorization bypass vulnerability in LXD allows an authenticated attacker to bypass project-level container isolation restrictions. When a project is configured with restrictions on container privileges (such as enforcing restricted.containers.privilege=isolated), LXD fails to enforce the requirement if an instance configuration omits the security.idmap.isolated key. An attacker can exploit this flaw by creating or updating an instance without explicitly setting security.idmap.isolated, bypassing the target project's security constraints.

AnalysisAI

Authorization bypass in LXD (Canonical) allows authenticated project members to circumvent container privilege isolation restrictions enforced at the project level. When a project is configured with restricted.containers.privilege=isolated, LXD's enforcement logic fails to apply the restriction if an instance is created or updated without explicitly setting the security.idmap.isolated key - effectively treating omission as permission. No public exploit code or CISA KEV listing exists at time of analysis, but the bypass is exploitable by any authenticated LXD user with instance-creation rights in a restricted project.

Technical ContextAI

LXD is Canonical's system container and virtual machine manager, widely used in Ubuntu-based infrastructure. Projects in LXD support resource and security restriction policies; restricted.containers.privilege=isolated is a project-level control intended to mandate that all containers use isolated UID/GID mappings via security.idmap.isolated, preventing privilege escalation out of container namespaces. The flaw (CWE-863: Incorrect Authorization) is a logic gap in LXD's restriction enforcement: the check evaluates whether security.idmap.isolated is set to a disallowed value, but does not account for the key being entirely absent from the instance configuration. The affected product is cpe:2.3:a:canonical:lxd:*:*:*:*:*:*:*:* - all versions per NVD CPE. The advisory is published by Canonical at GHSA-7vp9-3vmp-c5jm.

RemediationAI

Upgrade LXD to the patched version referenced in the Canonical security advisory at https://github.com/canonical/lxd/security/advisories/GHSA-7vp9-3vmp-c5jm - the exact fixed release version is not independently confirmed from available data and must be verified in the advisory. As a compensating control prior to patching, administrators should audit all existing instance configurations within restricted projects to ensure security.idmap.isolated is explicitly set to true on every instance, rather than relying on the project-level restriction alone. Additionally, LXD project membership and instance-creation rights should be restricted to trusted users only, since the bypass requires authenticated access (PR:L). Note that explicit instance-level key enforcement adds per-instance administrative overhead and may conflict with automation pipelines that rely on project-level policy inheritance.