Arbitrary host file read and write in Canonical LXD via metadata.yaml symlink

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.

Canonical LXD on Linux is marked default unaffected except for these release branches:

• 4.0.0 through less than 4.0.12.
• 5.0.0 through less than 5.0.8.
• 5.21.0 through less than 5.21.6.
• 6.0 through less than 6.10.

Canonical's advisory identifies the corresponding patched releases as 4.0.12, 5.0.8, 5.21.6, and 6.10. The available evidence does not separately establish the status of downstream packages with backported fixes, renamed packages, or parallel release branches, which should be verified with the relevant distributor.

LXD uses tar with --restrict --force-local while unpacking an image archive. The --restrict flag prevents following symlinks outside the extraction root, but it does not prevent symlink entries from being created, so a top-level metadata.yaml can remain a symlink after extraction. In cmd/incusd/instance_metadata.go, LXD builds the path with filepath.Join(inst.Path(), "metadata.yaml"), then reads it with os.Open and writes it with os.WriteFile without an Lstat check or an os.OpenRoot confinement guard. The attacker-controlled body of a PUT request can therefore be written verbatim to the symlink target with root privileges. This is CWE-59, Improper Link Resolution Before File Access, also known as link following. Exploitation requires an authenticated account able to use the relevant image and metadata operations through a network-reachable daemon API, but it does not require end-user interaction. The available evidence does not establish the exact authorization policy in every deployment or the status of downstream packages with backported fixes.

The flaw is reachable through the daemon API over the network and requires an authenticated account with limited privileges, consistent with the network reachability and low privilege requirements recorded for the issue. An attacker must provide a crafted image archive and perform the relevant instance metadata operations; the exact authorization requirement should be checked against each deployment's access policy. Canonical's advisory includes a public proof of concept, so public exploitation details are available. The record does not establish exploitation in the wild or identify a specific campaign. The advisory also states that exploitation does not require a privileged container, a running workload, or a kernel exploit, and that this is not a container escape.

The flaw allows the daemon to read from a symlink target and write attacker-controlled data to a host file with root privileges. Technical consequences can include disclosure of data outside the instance boundary, modification of configuration files, creation of root-owned files, and corruption of files that causes host services to fail. Because the operation occurs through the daemon API, the impact can cross the expected LXD isolation boundary and affect the host. The advisory states that this is not a container escape and does not require a kernel exploit, but the attacker still needs an authenticated account with appropriate access. The available evidence does not establish that every deployment exposes the same set of host paths or grants the same level of access.

The flaw can expose host data outside the intended instance boundary, including configuration or credential material where the targeted files contain it. It can also create or overwrite host files with root privileges, which may enable configuration tampering or persistence. For non-YAML targets, creating or corrupting a file may disrupt a host service or cause denial of service. The impact therefore reaches the host rather than remaining within the instance, although exploitation still requires an authenticated account with permission to perform the relevant operations.

1. Upgrade each system to the exact patched release identified by Canonical for its current branch: 4.0.12 for the 4.0.x branch, 5.0.8 for the 5.0.x branch, 5.21.6 for the 5.21.x branch, or 6.10 for the 6.x branch.
2. Do not use 5.12.6 as the fix for the 5.21.x branch. That value appears in the supplied solution text, but it conflicts with the affected range 5.21.0 through less than 5.21.6 and with Canonical's advisory, which identifies 5.21.6.
3. Verify the actual binary or package version after upgrading, especially where LXD is distributed by an operating system that may backport the fix without matching the upstream version. If the distributor uses a separate patch, confirm it against the distributor's security notice before marking the system remediated.
4. The consulted evidence does not document a vendor-confirmed temporary workaround. Until upgrading, restricting image imports and instance metadata access to trusted accounts may reduce exposure as a precaution, but it is not a substitute for the patch.
5. After upgrading, review images imported from untrusted sources and host-file changes that occurred after image or metadata operations to assess whether exploitation may have occurred before remediation.

1. Inventory the actual LXD version on each host and compare it with the affected branches in affected_summary, including distribution packages and backported builds.
2. Identify authenticated accounts that can import or unpack images and call instance metadata operations. Include project-level permissions where the deployment uses that access model.
3. Inspect image archives before import to determine whether metadata.yaml is a symlink. Do not treat an archive's source reputation as proof that its contents are safe without checking the archive itself.
4. Where audit logging is available, review image imports and requests to GET /1.0/instances/{name}/metadata or PUT /1.0/instances/{name}/metadata, especially when associated with unfamiliar accounts or images. This is precautionary monitoring, not a Canonical-confirmed indicator of compromise.
5. Check for unexpected host-file changes, particularly files created or modified by the daemon with root ownership after image imports or metadata operations. The absence of suspicious logs or file changes does not prove that the system is safe.