Lxd
Monthly
Improper certificate validation in the HTTPS API listener of Canonical LXD lets an unauthenticated remote attacker present a crafted certificate chain that is accepted as an already-trusted client, granting full access to the LXD cluster and the virtual machines it manages. Affected builds are 4.0.14, 5.0.10, 5.21.8, and 6.9 and earlier within each branch; the fixed releases are 4.0.15, 5.0.11, 5.21.9, and 6.10.1. Exploitation requires that the HTTPS listener be enabled and network-reachable, so installations restricted to the local Unix socket are not remotely exposed; clustered LXD and MicroCloud deployments, which depend on this listener, carry the most risk. The vulnerability is rated 10.0 under CVSS 4.0 with no privileges or user interaction required (PR:N/UI:N), and no public exploit code was identified at time of analysis, though the vendor rates the issue as requiring immediate action.
Arbitrary file write as root in Canonical LXD 4.0 and later (before 4.0.14, 5.0.10, 5.21.8 and 6.10) on Linux lets an authenticated client with permission to create instances or custom storage volumes in a project - or a malicious migration source server - plant a symlink inside a transferred volume and then write through it to any path on the target host, resulting in full host compromise. Exploitation requires triggering a volume migration receive and supplying a crafted rsync or btrfs send stream that plants a symlink at a name such as rootfs or root.img; the flaw is an improper link resolution issue (CWE-59) in the receive path that does not confine link targets to the volume. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis, though the independent assessment rates this a genuine high-priority vulnerability rather than a CVSS-inflated one given the authenticated, low-privilege path to root.
Incorrect authorization in Canonical LXD 5.0.0 through versions before 5.0.10, 5.21.8, and 6.10 allows an authenticated client with permission to create custom storage volumes in one project to copy and read any custom volume, including its snapshots and configuration, from any other project on the same server. The flaw resides in the custom storage volume creation endpoint, where a crafted request that sets a source volume and source.project but omits source.type bypasses the cross-project authorization check. This affects multi-project LXD deployments only, requires low privileges (PR:L), and yields high confidentiality impact (CVSS 7.7, AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N); no public exploit code or confirmed active exploitation was identified at time of analysis.
Path traversal in the btrfs storage driver of Canonical LXD 4.0.2 and later allows an authenticated client that holds project-scoped permission to create instances to delete arbitrary files on the host as root by supplying a crafted subvolume path containing ../ sequences, and on hosts whose root filesystem is itself btrfs the same primitive escalates to placing attacker-controlled content at arbitrary host paths for full host compromise. The issue is rated CVSS v3.1 9.6 (AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H), reflecting a scope-changing breakout from a restricted tenant role into the host root context rather than a CVSS-inflated score, since a legitimate but limited project credential is the only prerequisite. No CISA KEV listing and no public exploit code were identified at time of analysis; vendor fixes are available in LXD 4.0.14, 5.0.10, 5.21.8 and 6.10.
Path traversal in Canonical LXD's Btrfs storage driver allows an authenticated user with instance-creation privileges to escape the intended backup import target and delete or replace arbitrary files and directories on the host as root, by supplying a crafted subvolumes[].path value in backup/optimized_header.yaml during a btrfs 'optimized' backup import. The assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) reflects high confidentiality, integrity and availability impact with a scope change because the traversed write lands outside the LXD daemon's own container boundary; exploitation requires valid low-privilege API credentials and a Btrfs-backed host, not anonymous access. No public exploit code has been identified at time of analysis, and the issue is not confirmed actively exploited (CISA KEV), but the low attack complexity and root-level file-system effect make it a genuine high-priority fix rather than a CVSS-inflated score.
Host root code execution in Canonical LXD arises from a path-traversal flaw in instance template processing, letting an attacker with container edit permissions - or any user who launches a maliciously crafted image - overwrite arbitrary root-owned files on the host. The root cause is a validate-then-open mismatch: LXD checks template target paths against a confined os.Root handle but then creates the file via os.Create using the raw, unconfined string path. No public exploit has been identified at time of analysis, but the CVSS 9.9 rating and container-to-host scope change make this a critical container-escape.
Privilege escalation to host root in Canonical LXD occurs when the container manager unpacks crafted image or backup archives, because it follows a symbolic link where the backup.yaml metadata file should be and then processes attacker-controlled configuration outside its intended confinement. A low-privileged LXD user who can import a malicious archive can execute arbitrary commands as root on the underlying host, breaking the container/host trust boundary (scope change). Rated CVSS 9.9; no public exploit identified at time of analysis and not listed in CISA KEV, but the fix is coordinated through GitHub advisory GHSA-fv82-v4fj-mm4m.
Arbitrary host file read and write in Canonical LXD occurs because the image import/unpack routine does not verify whether the bundled metadata.yaml entry is a symbolic link, letting an authenticated user with image-import rights supply a crafted archive whose symlinked metadata.yaml resolves to sensitive host paths. Rated CVSS 9.9 with a scope change (S:C), successful exploitation crosses the container/management boundary to read or overwrite files as the LXD daemon (typically root) on the host. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV; details are published only in Canonical advisory GHSA-j825-cg34-5fr5.
Path traversal in Canonical LXD's image metadata template processing enables an authenticated low-privilege attacker to read arbitrary host files or create files in arbitrary host filesystem locations. The flaw resides in the virtual machine/QEMU driver execution path, where LXD fails to sanitize template file paths from escaping the designated instance templates directory. Exploitation crosses the container/VM boundary to the host (scope change, S:C), making this high-severity in environments where host isolation is a security assumption. No public exploit code or CISA KEV listing has been identified at time of analysis.
Path traversal in Canonical's LXD container and VM manager allows a user with backup import/restore privileges to write or read files outside the intended restore directory by embedding traversal sequences in the instance or storage-volume names stored in a crafted backup archive's metadata. Because LXD does not validate these names on import/restore, an attacker can corrupt or overwrite host files, potentially leading to full host compromise. There is no public exploit identified at time of analysis, and it is not listed in CISA KEV; the very high CVSS (9.9) is driven by the scope-changing, high-integrity/availability impact on the host.
Authorization bypass in Canonical LXD lets an authenticated user with instance-migration privileges smuggle high-privilege instance configurations into restricted projects. When an instance is migrated to a target project, LXD applies caller-supplied configuration overrides without re-validating them against the destination project's enforced restrictions, so security controls such as privileged-container or device limits can be defeated. Rated CVSS 9.9 (CWE-863) with a scope-changing impact; no public exploit has been identified at time of analysis.
Authorization bypass in Canonical LXD lets an authenticated user with copy privileges smuggle instances carrying disallowed high-privilege configurations into restricted projects, defeating per-project security controls. The root cause is a time-of-check to time-of-use race in which LXD validates project restrictions before configuration merging finishes during cross-project instance copies. Rated CVSS 9.9 with a scope change; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Canonical LXD's NVIDIA GPU passthrough configuration handler fails to sanitize newline characters in user-supplied `nvidia.driver.capabilities` and `nvidia.require.*` instance config values, enabling an authenticated attacker to inject arbitrary directives into the generated `lxc.conf` file. Any LXD user with instance-creation or configuration-modification privileges can exploit this to escape the container boundary and execute arbitrary commands on the host with the full privileges of the LXD daemon - effectively achieving complete host compromise. No public exploit code or CISA KEV listing exists at time of analysis, but the network-accessible, low-privilege attack path and scope-changed CVSS vector reflect an elevated real-world threat for shared or multi-tenant LXD deployments.
Storage quota bypass in Canonical LXD (5.0.x before 5.0.8, 5.21.x before 5.21.6, and 6.0 before 6.10) lets an authenticated user exceed the disk and volume limits an administrator configured on a project. The flaw stems from two code paths - cross-project volume moves (storagePoolVolumeTypePostMove) and volume snapshot restores with a nil config - that skip the AllowVolumeCreation/AllowVolumeUpdate limit checks, enabling over-allocation of storage. Reported by Canonical with a patch available; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Authorization bypass in Canonical LXD (6.0 before 6.10, 5.21.x before 5.21.6, 5.0.x before 5.0.8) lets an authenticated user smuggle disallowed instance configurations into a restricted project by triggering a cross-project, cross-cluster-member migration. Because the migration arrives at the destination node as an internal cluster notification, the destination skips all target-project restriction checks (CWE-863), so limits and security restrictions on the target project are not enforced. Rated CVSS 9.9; reported by Canonical with a vendor patch available, but no public exploit identified at time of analysis and it is not listed in CISA KEV.
Project-confinement bypass in Canonical LXD lets an authenticated user holding can_create_instances on a restricted project escape that project's security policy by migrating an instance into it. Because instancePostMigration never re-validated the incoming instance against the target project's enforced restrictions, an attacker could build a high-privilege or otherwise disallowed instance inside an unrestricted project and relocate it into the restricted one, inheriting capabilities (low-level container access, arbitrary devices, unrestricted network access) that the project was configured to forbid. Rated CVSS 9.9 by the vendor; no public exploit identified at time of analysis and it is not in CISA KEV.
Privilege escalation in Canonical LXD (versions 6.0-6.8, 5.21.0-5.21.4, and 5.0.0-5.0.6) allows an authenticated project operator in a restricted multi-tenant deployment to escape tenant confinement and obtain host root. Because project-restriction policies are not re-validated when an instance backup is imported and its snapshot restored, an operator can smuggle restricted configuration keys into a snapshot, restore them onto the live instance, and start it to gain unauthorized root on the host. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV, but a vendor patch and the fixing source code are available.
Cross-guest storage-volume hijacking in Canonical LXD 6.6 through 6.8 lets an untrusted guest instance mount, read, and overwrite the custom storage volumes owned by other guests on the same host, breaking tenant isolation. Exploitation requires the non-default security.devlxd.management.volumes option to be enabled, and is fixed in LXD 6.9. Rated CVSS 9.6 with a scope change and CISA SSVC 'total' technical impact; SSVC lists exploitation as proof-of-concept, but EPSS is very low (0.11%, 1st percentile) and it is not in CISA KEV.
Privilege escalation in Canonical LXD 4.12 through 6.7 enables remote authenticated restricted TLS certificate users to gain cluster admin privileges. Exploitation requires high-privilege authentication (PR:H) but no user interaction. The vulnerability stems from missing Type field validation in doCertificateUpdate function when processing PUT/PATCH requests to the certificates API endpoint. Attack scope is changed (S:C), allowing attackers to break containment and achieve full cluster compromise with high impact to confidentiality, integrity, and availability. No public exploit identified at time of analysis.
Backup import in Canonical LXD before 6.8 bypasses project security restrictions, enabling privilege escalation to full host compromise. An authenticated remote attacker with instance-creation permission in a restricted project crafts malicious backup archives containing conflicting configuration files: backup/index.yaml passes validation, while backup/container/backup.yaml (never validated) carries forbidden directives like security.privileged=true or raw.lxc commands. Exploiting this dual-file validation gap allows unrestricted container creation that breaks isolation boundaries. No public exploit identified at time of analysis.
Privilege escalation in Canonical LXD 4.12-6.7 allows authenticated remote attackers with VM instance editing rights to bypass project restrictions via incomplete denylist validation. Attackers inject AppArmor rules and QEMU chardev configurations through unblocked raw.apparmor and raw.qemu.conf keys, bridging the LXD Unix socket into guest VMs. Successful exploitation enables escalation to LXD cluster administrator and subsequently to host root access. No public exploit identified at time of analysis. Authenticated remote exploitation (PR:H) with cross-scope impact on confidentiality, integrity, and availability.
Remote code execution in Canonical LXD 4.12 through 6.6 lets an authenticated but unprivileged LXD API user run arbitrary commands as the root-level LXD daemon by injecting shell content into the compression_algorithm parameter of the image-publish and backup-export endpoints. The daemon passed this attacker-supplied string to a compression command lookup without allowlisting it, turning a routine 'choose your compressor' option into full host takeover. No public exploit is identified at time of analysis and EPSS is low (0.12%), but the root cause is confirmed by Canonical's own security advisory and upstream commits.
Arbitrary file and directory-tree writes on an LXD client host can be achieved through the recursive file pull feature of the LXD CLI in Canonical LXD 4.0.2 through 6.9 on Linux. An attacker who already holds root inside a guest VM (CVSS PR:L) substitutes a modified lxd-agent that returns inconsistent SFTP directory listings and Lstat results, then waits for the host operator to invoke a recursive pull against that VM (UI:R); the difficulty of forging those inconsistent responses is captured by AC:H, and the write lands on the host with the operator's privileges (S:C, I:H, C:N, A:N). This is CWE-59 improper link resolution, no public exploit code was identified at time of analysis, and vendor patches are available in 4.0.14, 5.0.10, and 5.21.8.
Canonical LXD before 5.0.10, 5.21.8, and 6.10 lets a project-restricted client read its own private images from other projects through local fingerprint reuse during image or instance import requests. The flaw is a missing-authorization condition (CWE-862) graded CVSS 6.3 (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N), meaning an attacker needs a valid but low-privileged credential and a multi-tenant deployment where a private image is already cached locally by another project; impact is limited to confidentiality of other projects' image content, with no code execution, write, or denial-of-service effect. No public exploit code or confirmed active exploitation was identified at time of analysis, and vendor patches are available. This is a genuine but moderate-severity project-isolation weakness rather than a critical one, and single-project or non-shared LXD hosts are not exposed.
Path traversal in the Canonical LXD CLI image export and copy code (client/lxd_images.go) lets a malicious or machine-in-the-middle image server steer the filename used for a downloaded image outside the local destination directory via a crafted Content-Disposition header, allowing arbitrary local file overwrite that can lead to code execution as the invoking user. Affected releases are LXD 4.0.2 through 4.0.13, 5.0.x before 5.0.10, 5.21.x before 5.21.8, and 6.x before 6.10; exploitation requires the victim to actively run `lxc image export` or `lxc image copy` into a local directory while pulling from an attacker-controlled or intercepted remote (CVSS 3.1 base 4.2, AV:N/AC:H/PR:N/UI:R, unauthenticated network attacker but with required user interaction). No public exploit code has been identified at time of analysis, and the issue is publicly documented with vendor-released patches and upstream pull requests already merged.
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.
Server-Side Request Forgery in Canonical LXD's image import endpoint allows authenticated users holding the can_create_images entitlement to direct the LXD daemon to make arbitrary outbound HTTP connections, including to loopback addresses, RFC1918 private ranges, and cloud instance metadata services such as 169.254.169.254. Affected versions span 4.12 through 6.9. An attacker can leverage error-based responses to enumerate internal TCP ports and fingerprint internal HTTP services from the daemon's privileged network position, enabling lateral reconnaissance in multi-tenant or cloud-hosted environments. No public exploit code has been identified at time of analysis, and CISA has not listed this in KEV.
Nil-pointer dereference in LXD's CreateCustomVolumeFromBackup function allows an authenticated user with can_create_storage_volumes permissions to crash the LXD daemon via a crafted backup tarball, affecting all containers running on the host. Versions up to 6.8 (current branch) and 5.21 (LTS branch) on Linux are vulnerable. No public exploit or CISA KEV listing exists at time of analysis, but upstream fix commits are available from Canonical.
Canonical LXD 6.6 on Linux contains an authorization bypass in the GET /1.0/certificates API endpoint that allows authenticated users with restricted privileges to enumerate all certificate fingerprints trusted by the server. Public exploit code exists for this vulnerability. While this enables information disclosure with limited impact, it could facilitate further attacks by revealing trust relationships on the system.
Authenticated remote attackers with access to the Canonical LXD instance log retrieval or deletion endpoints can read arbitrary files on the host through a path traversal flaw (CWE-22) in the validLogFileName validation routine used by the LXD 5.0 LTS series. Exploitation requires a valid LXD account (CVSS PR:L, no user interaction), and because the daemon runs with root privileges, successfully read files can include any host file readable by root; publicly available exploit code exists and the issue is reachable through the LXD API or the LXD-UI. The defect is corrected in LXD 5.21.4 and 6.5, but the upstream fix (PR #15022) was aimed at code cleanup and no dedicated security patch was issued for the 5.0 LTS branch, so 5.0 LTS deployments remain affected; EPSS is low at roughly 0.07% (20th percentile) and there is no CISA KEV confirmation of active exploitation.
Path traversal in Canonical LXD-UI, the web console shipped with LXD, lets an authenticated user read or modify resources outside the intended scope by embedding traversal sequences in resource names submitted through URL paths; only the 6.0 branch before 6.5 and the 5.21 branch before 5.21.4 are affected. Exploitation requires the attacker to already hold valid credentials for the LXD-UI web interface and some user interaction is indicated by the vendor vector, so unauthenticated internet attackers cannot trigger it and headless LXD API/CLI-only deployments are not exposed. Publicly available exploit code exists (referenced via the vendor GitHub security advisory), but there is no confirmation of active exploitation; EPSS is 0.04% (10th percentile), consistent with a moderate-risk, low-priority issue despite the available proof-of-concept.
Unauthenticated remote attackers can confirm the existence of LXD projects on Canonical LXD by comparing HTTP status codes returned from the /1.0/images API, which is registered as an AllowUntrusted endpoint that requires no account. The endpoint replies 404 for a non-existent project but 403 for an existing one, producing a project-enumeration oracle with limited confidentiality impact; a publicly available exploit code exists in the form of the upstream GHSA reproduction steps, but there is no confirmed active exploitation and EPSS is low at roughly 0.09% (25th percentile). The practical exposure is bounded because LXD only listens on a network HTTPS socket when core.https_address has been deliberately enabled, and the flaw reveals nothing beyond project name existence.
Unauthenticated project enumeration in Canonical LXD 5.21.x before 5.21.4 and 6.x before 6.5 lets remote attackers determine whether a specific project name exists by abusing inconsistent error handling in the image export API. Because the fingerprint path segment is matched against SQL LIKE wildcards, a request such as /1.0/images/%25/export?project=X returns HTTP 500 'More than one image matches' when the project exists but HTTP 404 when it does not, enabling dictionary-style brute forcing of project names. No authentication or user interaction is required (CVSS:4.0 PR:N/UI:N, independently assessed as CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), publicly available exploit code exists, and EPSS is low at 0.09% (26th percentile); impact is limited to confirming project existence rather than disclosing image or credential contents, and default installations that only bind the local Unix socket are not exposed.
Privilege escalation in Canonical LXD's operations API (LXD before 6.5 and LXD 5.21 before 5.21.4) allows an authenticated user who holds only read permissions to hijack a terminal or console WebSocket session opened by another user and execute arbitrary commands with that victim's privileges. Publicly available exploit code exists (a JavaScript proof-of-concept published with the GHSA advisory), and exploitation requires a concurrently active exec session to hijack, so conditions are timing-dependent rather than trivially repeatable. The issue is not listed in CISA KEV, and EPSS is low at 0.04% (12th percentile), indicating no observed mass exploitation; vendor-released fixes are available in 5.21.4 and 6.5.
Container impersonation in Canonical LXD's devLXD server lets an attacker who already holds root inside one container read another container's metadata, configuration and device information by forging their process command line to look like another container's monitor process. Affected builds are LXD 4.0 through 5.21.x (fixed in 5.21.4) and 6.0 through 6.5.x (fixed in 6.5), including matching Go module versions; the vendor advisory GHSA-7232-97c6-j525 includes a full reproduction, so publicly available exploit code exists, though there is no KEV-listed active exploitation and EPSS is only 0.06% (17th percentile) because root inside a container is required (CVSS 4.0 vector rates it 5.1 with PR:H; our assessment is CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N). The impact is confidentiality-only - cross-container and cross-project information disclosure, not code execution or data modification - making it a genuine but moderate-priority problem that matters most on multi-tenant or multi-project hosts.
Server-side template injection in Canonical LXD's instance snapshot naming feature lets an authenticated user who can modify instance configuration read arbitrary files on the LXD host. The snapshots.pattern setting is rendered by the Pongo2 template engine without sandboxing, so tags such as include, ssi, extends, and import can pull in files like /etc/passwd, /etc/shadow, LXD database files, and other tenants' instance data. Publicly available exploit code exists (a crafted pattern using urlencode and slice filters to bypass length limits), though there is no confirmed active exploitation (CISA KEV) and EPSS is low at 0.06% (19th percentile); the assessed vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N confirms this is a confidentiality-only impact requiring an authenticated account with delegated instance-configuration rights.
Cross-site request forgery in the LXD-UI component of Canonical LXD 5.0 before 5.0.5, 5.1 before 5.21.4, and 6.0 before 6.5 can make a victim's browser create and start a container without consent when the victim is authenticated to LXD via client certificate authentication and has permission to create instances in the targeted project. Exploitation requires the victim to visit an attacker-controlled page and depends on the target project's default profile having a default instance storage pool; OIDC-authenticated sessions are not affected because they rely on SameSite=Strict cookies. Publicly available exploit code exists, and EPSS is 0.02% (6th percentile). The assessed CVSS:3.1 vector is AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:L, indicating moderate priority.
Mark Laing discovered in LXD's PKI mode, until version 5.21.1, that a restricted certificate could be added to the trust store with its restrictions not honoured. Rated low severity (CVSS 3.8), this vulnerability is low attack complexity. Public exploit code available and no vendor patch available.
Mark Laing discovered that LXD's PKI mode, until version 5.21.2, could be bypassed if the client's certificate was present in the trust store. Rated low severity (CVSS 3.8), this vulnerability is low attack complexity. Public exploit code available and no vendor patch available.
LXD before 2.0.2 does not properly set permissions when switching an unprivileged container into privileged mode, which allows local users to access arbitrary world readable paths in the container. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. No vendor patch available.
LXD before 2.0.2 uses world-readable permissions for /var/lib/lxd/zfs.img when setting up a loop based ZFS pool, which allows local users to copy and read data from arbitrary containers via. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. No vendor patch available.
Improper certificate validation in the HTTPS API listener of Canonical LXD lets an unauthenticated remote attacker present a crafted certificate chain that is accepted as an already-trusted client, granting full access to the LXD cluster and the virtual machines it manages. Affected builds are 4.0.14, 5.0.10, 5.21.8, and 6.9 and earlier within each branch; the fixed releases are 4.0.15, 5.0.11, 5.21.9, and 6.10.1. Exploitation requires that the HTTPS listener be enabled and network-reachable, so installations restricted to the local Unix socket are not remotely exposed; clustered LXD and MicroCloud deployments, which depend on this listener, carry the most risk. The vulnerability is rated 10.0 under CVSS 4.0 with no privileges or user interaction required (PR:N/UI:N), and no public exploit code was identified at time of analysis, though the vendor rates the issue as requiring immediate action.
Arbitrary file write as root in Canonical LXD 4.0 and later (before 4.0.14, 5.0.10, 5.21.8 and 6.10) on Linux lets an authenticated client with permission to create instances or custom storage volumes in a project - or a malicious migration source server - plant a symlink inside a transferred volume and then write through it to any path on the target host, resulting in full host compromise. Exploitation requires triggering a volume migration receive and supplying a crafted rsync or btrfs send stream that plants a symlink at a name such as rootfs or root.img; the flaw is an improper link resolution issue (CWE-59) in the receive path that does not confine link targets to the volume. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis, though the independent assessment rates this a genuine high-priority vulnerability rather than a CVSS-inflated one given the authenticated, low-privilege path to root.
Incorrect authorization in Canonical LXD 5.0.0 through versions before 5.0.10, 5.21.8, and 6.10 allows an authenticated client with permission to create custom storage volumes in one project to copy and read any custom volume, including its snapshots and configuration, from any other project on the same server. The flaw resides in the custom storage volume creation endpoint, where a crafted request that sets a source volume and source.project but omits source.type bypasses the cross-project authorization check. This affects multi-project LXD deployments only, requires low privileges (PR:L), and yields high confidentiality impact (CVSS 7.7, AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N); no public exploit code or confirmed active exploitation was identified at time of analysis.
Path traversal in the btrfs storage driver of Canonical LXD 4.0.2 and later allows an authenticated client that holds project-scoped permission to create instances to delete arbitrary files on the host as root by supplying a crafted subvolume path containing ../ sequences, and on hosts whose root filesystem is itself btrfs the same primitive escalates to placing attacker-controlled content at arbitrary host paths for full host compromise. The issue is rated CVSS v3.1 9.6 (AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H), reflecting a scope-changing breakout from a restricted tenant role into the host root context rather than a CVSS-inflated score, since a legitimate but limited project credential is the only prerequisite. No CISA KEV listing and no public exploit code were identified at time of analysis; vendor fixes are available in LXD 4.0.14, 5.0.10, 5.21.8 and 6.10.
Path traversal in Canonical LXD's Btrfs storage driver allows an authenticated user with instance-creation privileges to escape the intended backup import target and delete or replace arbitrary files and directories on the host as root, by supplying a crafted subvolumes[].path value in backup/optimized_header.yaml during a btrfs 'optimized' backup import. The assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) reflects high confidentiality, integrity and availability impact with a scope change because the traversed write lands outside the LXD daemon's own container boundary; exploitation requires valid low-privilege API credentials and a Btrfs-backed host, not anonymous access. No public exploit code has been identified at time of analysis, and the issue is not confirmed actively exploited (CISA KEV), but the low attack complexity and root-level file-system effect make it a genuine high-priority fix rather than a CVSS-inflated score.
Host root code execution in Canonical LXD arises from a path-traversal flaw in instance template processing, letting an attacker with container edit permissions - or any user who launches a maliciously crafted image - overwrite arbitrary root-owned files on the host. The root cause is a validate-then-open mismatch: LXD checks template target paths against a confined os.Root handle but then creates the file via os.Create using the raw, unconfined string path. No public exploit has been identified at time of analysis, but the CVSS 9.9 rating and container-to-host scope change make this a critical container-escape.
Privilege escalation to host root in Canonical LXD occurs when the container manager unpacks crafted image or backup archives, because it follows a symbolic link where the backup.yaml metadata file should be and then processes attacker-controlled configuration outside its intended confinement. A low-privileged LXD user who can import a malicious archive can execute arbitrary commands as root on the underlying host, breaking the container/host trust boundary (scope change). Rated CVSS 9.9; no public exploit identified at time of analysis and not listed in CISA KEV, but the fix is coordinated through GitHub advisory GHSA-fv82-v4fj-mm4m.
Arbitrary host file read and write in Canonical LXD occurs because the image import/unpack routine does not verify whether the bundled metadata.yaml entry is a symbolic link, letting an authenticated user with image-import rights supply a crafted archive whose symlinked metadata.yaml resolves to sensitive host paths. Rated CVSS 9.9 with a scope change (S:C), successful exploitation crosses the container/management boundary to read or overwrite files as the LXD daemon (typically root) on the host. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV; details are published only in Canonical advisory GHSA-j825-cg34-5fr5.
Path traversal in Canonical LXD's image metadata template processing enables an authenticated low-privilege attacker to read arbitrary host files or create files in arbitrary host filesystem locations. The flaw resides in the virtual machine/QEMU driver execution path, where LXD fails to sanitize template file paths from escaping the designated instance templates directory. Exploitation crosses the container/VM boundary to the host (scope change, S:C), making this high-severity in environments where host isolation is a security assumption. No public exploit code or CISA KEV listing has been identified at time of analysis.
Path traversal in Canonical's LXD container and VM manager allows a user with backup import/restore privileges to write or read files outside the intended restore directory by embedding traversal sequences in the instance or storage-volume names stored in a crafted backup archive's metadata. Because LXD does not validate these names on import/restore, an attacker can corrupt or overwrite host files, potentially leading to full host compromise. There is no public exploit identified at time of analysis, and it is not listed in CISA KEV; the very high CVSS (9.9) is driven by the scope-changing, high-integrity/availability impact on the host.
Authorization bypass in Canonical LXD lets an authenticated user with instance-migration privileges smuggle high-privilege instance configurations into restricted projects. When an instance is migrated to a target project, LXD applies caller-supplied configuration overrides without re-validating them against the destination project's enforced restrictions, so security controls such as privileged-container or device limits can be defeated. Rated CVSS 9.9 (CWE-863) with a scope-changing impact; no public exploit has been identified at time of analysis.
Authorization bypass in Canonical LXD lets an authenticated user with copy privileges smuggle instances carrying disallowed high-privilege configurations into restricted projects, defeating per-project security controls. The root cause is a time-of-check to time-of-use race in which LXD validates project restrictions before configuration merging finishes during cross-project instance copies. Rated CVSS 9.9 with a scope change; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Canonical LXD's NVIDIA GPU passthrough configuration handler fails to sanitize newline characters in user-supplied `nvidia.driver.capabilities` and `nvidia.require.*` instance config values, enabling an authenticated attacker to inject arbitrary directives into the generated `lxc.conf` file. Any LXD user with instance-creation or configuration-modification privileges can exploit this to escape the container boundary and execute arbitrary commands on the host with the full privileges of the LXD daemon - effectively achieving complete host compromise. No public exploit code or CISA KEV listing exists at time of analysis, but the network-accessible, low-privilege attack path and scope-changed CVSS vector reflect an elevated real-world threat for shared or multi-tenant LXD deployments.
Storage quota bypass in Canonical LXD (5.0.x before 5.0.8, 5.21.x before 5.21.6, and 6.0 before 6.10) lets an authenticated user exceed the disk and volume limits an administrator configured on a project. The flaw stems from two code paths - cross-project volume moves (storagePoolVolumeTypePostMove) and volume snapshot restores with a nil config - that skip the AllowVolumeCreation/AllowVolumeUpdate limit checks, enabling over-allocation of storage. Reported by Canonical with a patch available; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Authorization bypass in Canonical LXD (6.0 before 6.10, 5.21.x before 5.21.6, 5.0.x before 5.0.8) lets an authenticated user smuggle disallowed instance configurations into a restricted project by triggering a cross-project, cross-cluster-member migration. Because the migration arrives at the destination node as an internal cluster notification, the destination skips all target-project restriction checks (CWE-863), so limits and security restrictions on the target project are not enforced. Rated CVSS 9.9; reported by Canonical with a vendor patch available, but no public exploit identified at time of analysis and it is not listed in CISA KEV.
Project-confinement bypass in Canonical LXD lets an authenticated user holding can_create_instances on a restricted project escape that project's security policy by migrating an instance into it. Because instancePostMigration never re-validated the incoming instance against the target project's enforced restrictions, an attacker could build a high-privilege or otherwise disallowed instance inside an unrestricted project and relocate it into the restricted one, inheriting capabilities (low-level container access, arbitrary devices, unrestricted network access) that the project was configured to forbid. Rated CVSS 9.9 by the vendor; no public exploit identified at time of analysis and it is not in CISA KEV.
Privilege escalation in Canonical LXD (versions 6.0-6.8, 5.21.0-5.21.4, and 5.0.0-5.0.6) allows an authenticated project operator in a restricted multi-tenant deployment to escape tenant confinement and obtain host root. Because project-restriction policies are not re-validated when an instance backup is imported and its snapshot restored, an operator can smuggle restricted configuration keys into a snapshot, restore them onto the live instance, and start it to gain unauthorized root on the host. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV, but a vendor patch and the fixing source code are available.
Cross-guest storage-volume hijacking in Canonical LXD 6.6 through 6.8 lets an untrusted guest instance mount, read, and overwrite the custom storage volumes owned by other guests on the same host, breaking tenant isolation. Exploitation requires the non-default security.devlxd.management.volumes option to be enabled, and is fixed in LXD 6.9. Rated CVSS 9.6 with a scope change and CISA SSVC 'total' technical impact; SSVC lists exploitation as proof-of-concept, but EPSS is very low (0.11%, 1st percentile) and it is not in CISA KEV.
Privilege escalation in Canonical LXD 4.12 through 6.7 enables remote authenticated restricted TLS certificate users to gain cluster admin privileges. Exploitation requires high-privilege authentication (PR:H) but no user interaction. The vulnerability stems from missing Type field validation in doCertificateUpdate function when processing PUT/PATCH requests to the certificates API endpoint. Attack scope is changed (S:C), allowing attackers to break containment and achieve full cluster compromise with high impact to confidentiality, integrity, and availability. No public exploit identified at time of analysis.
Backup import in Canonical LXD before 6.8 bypasses project security restrictions, enabling privilege escalation to full host compromise. An authenticated remote attacker with instance-creation permission in a restricted project crafts malicious backup archives containing conflicting configuration files: backup/index.yaml passes validation, while backup/container/backup.yaml (never validated) carries forbidden directives like security.privileged=true or raw.lxc commands. Exploiting this dual-file validation gap allows unrestricted container creation that breaks isolation boundaries. No public exploit identified at time of analysis.
Privilege escalation in Canonical LXD 4.12-6.7 allows authenticated remote attackers with VM instance editing rights to bypass project restrictions via incomplete denylist validation. Attackers inject AppArmor rules and QEMU chardev configurations through unblocked raw.apparmor and raw.qemu.conf keys, bridging the LXD Unix socket into guest VMs. Successful exploitation enables escalation to LXD cluster administrator and subsequently to host root access. No public exploit identified at time of analysis. Authenticated remote exploitation (PR:H) with cross-scope impact on confidentiality, integrity, and availability.
Remote code execution in Canonical LXD 4.12 through 6.6 lets an authenticated but unprivileged LXD API user run arbitrary commands as the root-level LXD daemon by injecting shell content into the compression_algorithm parameter of the image-publish and backup-export endpoints. The daemon passed this attacker-supplied string to a compression command lookup without allowlisting it, turning a routine 'choose your compressor' option into full host takeover. No public exploit is identified at time of analysis and EPSS is low (0.12%), but the root cause is confirmed by Canonical's own security advisory and upstream commits.
Arbitrary file and directory-tree writes on an LXD client host can be achieved through the recursive file pull feature of the LXD CLI in Canonical LXD 4.0.2 through 6.9 on Linux. An attacker who already holds root inside a guest VM (CVSS PR:L) substitutes a modified lxd-agent that returns inconsistent SFTP directory listings and Lstat results, then waits for the host operator to invoke a recursive pull against that VM (UI:R); the difficulty of forging those inconsistent responses is captured by AC:H, and the write lands on the host with the operator's privileges (S:C, I:H, C:N, A:N). This is CWE-59 improper link resolution, no public exploit code was identified at time of analysis, and vendor patches are available in 4.0.14, 5.0.10, and 5.21.8.
Canonical LXD before 5.0.10, 5.21.8, and 6.10 lets a project-restricted client read its own private images from other projects through local fingerprint reuse during image or instance import requests. The flaw is a missing-authorization condition (CWE-862) graded CVSS 6.3 (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N), meaning an attacker needs a valid but low-privileged credential and a multi-tenant deployment where a private image is already cached locally by another project; impact is limited to confidentiality of other projects' image content, with no code execution, write, or denial-of-service effect. No public exploit code or confirmed active exploitation was identified at time of analysis, and vendor patches are available. This is a genuine but moderate-severity project-isolation weakness rather than a critical one, and single-project or non-shared LXD hosts are not exposed.
Path traversal in the Canonical LXD CLI image export and copy code (client/lxd_images.go) lets a malicious or machine-in-the-middle image server steer the filename used for a downloaded image outside the local destination directory via a crafted Content-Disposition header, allowing arbitrary local file overwrite that can lead to code execution as the invoking user. Affected releases are LXD 4.0.2 through 4.0.13, 5.0.x before 5.0.10, 5.21.x before 5.21.8, and 6.x before 6.10; exploitation requires the victim to actively run `lxc image export` or `lxc image copy` into a local directory while pulling from an attacker-controlled or intercepted remote (CVSS 3.1 base 4.2, AV:N/AC:H/PR:N/UI:R, unauthenticated network attacker but with required user interaction). No public exploit code has been identified at time of analysis, and the issue is publicly documented with vendor-released patches and upstream pull requests already merged.
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.
Server-Side Request Forgery in Canonical LXD's image import endpoint allows authenticated users holding the can_create_images entitlement to direct the LXD daemon to make arbitrary outbound HTTP connections, including to loopback addresses, RFC1918 private ranges, and cloud instance metadata services such as 169.254.169.254. Affected versions span 4.12 through 6.9. An attacker can leverage error-based responses to enumerate internal TCP ports and fingerprint internal HTTP services from the daemon's privileged network position, enabling lateral reconnaissance in multi-tenant or cloud-hosted environments. No public exploit code has been identified at time of analysis, and CISA has not listed this in KEV.
Nil-pointer dereference in LXD's CreateCustomVolumeFromBackup function allows an authenticated user with can_create_storage_volumes permissions to crash the LXD daemon via a crafted backup tarball, affecting all containers running on the host. Versions up to 6.8 (current branch) and 5.21 (LTS branch) on Linux are vulnerable. No public exploit or CISA KEV listing exists at time of analysis, but upstream fix commits are available from Canonical.
Canonical LXD 6.6 on Linux contains an authorization bypass in the GET /1.0/certificates API endpoint that allows authenticated users with restricted privileges to enumerate all certificate fingerprints trusted by the server. Public exploit code exists for this vulnerability. While this enables information disclosure with limited impact, it could facilitate further attacks by revealing trust relationships on the system.
Authenticated remote attackers with access to the Canonical LXD instance log retrieval or deletion endpoints can read arbitrary files on the host through a path traversal flaw (CWE-22) in the validLogFileName validation routine used by the LXD 5.0 LTS series. Exploitation requires a valid LXD account (CVSS PR:L, no user interaction), and because the daemon runs with root privileges, successfully read files can include any host file readable by root; publicly available exploit code exists and the issue is reachable through the LXD API or the LXD-UI. The defect is corrected in LXD 5.21.4 and 6.5, but the upstream fix (PR #15022) was aimed at code cleanup and no dedicated security patch was issued for the 5.0 LTS branch, so 5.0 LTS deployments remain affected; EPSS is low at roughly 0.07% (20th percentile) and there is no CISA KEV confirmation of active exploitation.
Path traversal in Canonical LXD-UI, the web console shipped with LXD, lets an authenticated user read or modify resources outside the intended scope by embedding traversal sequences in resource names submitted through URL paths; only the 6.0 branch before 6.5 and the 5.21 branch before 5.21.4 are affected. Exploitation requires the attacker to already hold valid credentials for the LXD-UI web interface and some user interaction is indicated by the vendor vector, so unauthenticated internet attackers cannot trigger it and headless LXD API/CLI-only deployments are not exposed. Publicly available exploit code exists (referenced via the vendor GitHub security advisory), but there is no confirmation of active exploitation; EPSS is 0.04% (10th percentile), consistent with a moderate-risk, low-priority issue despite the available proof-of-concept.
Unauthenticated remote attackers can confirm the existence of LXD projects on Canonical LXD by comparing HTTP status codes returned from the /1.0/images API, which is registered as an AllowUntrusted endpoint that requires no account. The endpoint replies 404 for a non-existent project but 403 for an existing one, producing a project-enumeration oracle with limited confidentiality impact; a publicly available exploit code exists in the form of the upstream GHSA reproduction steps, but there is no confirmed active exploitation and EPSS is low at roughly 0.09% (25th percentile). The practical exposure is bounded because LXD only listens on a network HTTPS socket when core.https_address has been deliberately enabled, and the flaw reveals nothing beyond project name existence.
Unauthenticated project enumeration in Canonical LXD 5.21.x before 5.21.4 and 6.x before 6.5 lets remote attackers determine whether a specific project name exists by abusing inconsistent error handling in the image export API. Because the fingerprint path segment is matched against SQL LIKE wildcards, a request such as /1.0/images/%25/export?project=X returns HTTP 500 'More than one image matches' when the project exists but HTTP 404 when it does not, enabling dictionary-style brute forcing of project names. No authentication or user interaction is required (CVSS:4.0 PR:N/UI:N, independently assessed as CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), publicly available exploit code exists, and EPSS is low at 0.09% (26th percentile); impact is limited to confirming project existence rather than disclosing image or credential contents, and default installations that only bind the local Unix socket are not exposed.
Privilege escalation in Canonical LXD's operations API (LXD before 6.5 and LXD 5.21 before 5.21.4) allows an authenticated user who holds only read permissions to hijack a terminal or console WebSocket session opened by another user and execute arbitrary commands with that victim's privileges. Publicly available exploit code exists (a JavaScript proof-of-concept published with the GHSA advisory), and exploitation requires a concurrently active exec session to hijack, so conditions are timing-dependent rather than trivially repeatable. The issue is not listed in CISA KEV, and EPSS is low at 0.04% (12th percentile), indicating no observed mass exploitation; vendor-released fixes are available in 5.21.4 and 6.5.
Container impersonation in Canonical LXD's devLXD server lets an attacker who already holds root inside one container read another container's metadata, configuration and device information by forging their process command line to look like another container's monitor process. Affected builds are LXD 4.0 through 5.21.x (fixed in 5.21.4) and 6.0 through 6.5.x (fixed in 6.5), including matching Go module versions; the vendor advisory GHSA-7232-97c6-j525 includes a full reproduction, so publicly available exploit code exists, though there is no KEV-listed active exploitation and EPSS is only 0.06% (17th percentile) because root inside a container is required (CVSS 4.0 vector rates it 5.1 with PR:H; our assessment is CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N). The impact is confidentiality-only - cross-container and cross-project information disclosure, not code execution or data modification - making it a genuine but moderate-priority problem that matters most on multi-tenant or multi-project hosts.
Server-side template injection in Canonical LXD's instance snapshot naming feature lets an authenticated user who can modify instance configuration read arbitrary files on the LXD host. The snapshots.pattern setting is rendered by the Pongo2 template engine without sandboxing, so tags such as include, ssi, extends, and import can pull in files like /etc/passwd, /etc/shadow, LXD database files, and other tenants' instance data. Publicly available exploit code exists (a crafted pattern using urlencode and slice filters to bypass length limits), though there is no confirmed active exploitation (CISA KEV) and EPSS is low at 0.06% (19th percentile); the assessed vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N confirms this is a confidentiality-only impact requiring an authenticated account with delegated instance-configuration rights.
Cross-site request forgery in the LXD-UI component of Canonical LXD 5.0 before 5.0.5, 5.1 before 5.21.4, and 6.0 before 6.5 can make a victim's browser create and start a container without consent when the victim is authenticated to LXD via client certificate authentication and has permission to create instances in the targeted project. Exploitation requires the victim to visit an attacker-controlled page and depends on the target project's default profile having a default instance storage pool; OIDC-authenticated sessions are not affected because they rely on SameSite=Strict cookies. Publicly available exploit code exists, and EPSS is 0.02% (6th percentile). The assessed CVSS:3.1 vector is AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:L, indicating moderate priority.
Mark Laing discovered in LXD's PKI mode, until version 5.21.1, that a restricted certificate could be added to the trust store with its restrictions not honoured. Rated low severity (CVSS 3.8), this vulnerability is low attack complexity. Public exploit code available and no vendor patch available.
Mark Laing discovered that LXD's PKI mode, until version 5.21.2, could be bypassed if the client's certificate was present in the trust store. Rated low severity (CVSS 3.8), this vulnerability is low attack complexity. Public exploit code available and no vendor patch available.
LXD before 2.0.2 does not properly set permissions when switching an unprivileged container into privileged mode, which allows local users to access arbitrary world readable paths in the container. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. No vendor patch available.
LXD before 2.0.2 uses world-readable permissions for /var/lib/lxd/zfs.img when setting up a loop based ZFS pool, which allows local users to copy and read data from arbitrary containers via. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. No vendor patch available.