CVE-2026-9639

What it actually does

This flaw is a denial-of-service vulnerability in LXD's custom storage volume backup import path. An authenticated LXD user with permission to create storage volumes can submit a specially crafted custom-volume backup tarball that omits the expected `expires_at` snapshot field. During `CreateCustomVolumeFromBackup` processing, LXD dereferences a nil value instead of safely rejecting the malformed metadata, causing the LXD daemon or the affected request-handling process to crash. The vulnerability does not directly provide code execution, data disclosure, or privilege escalation, but it can interrupt container and storage management availability.

Why it matters to the business

Successful exploitation can disrupt LXD management operations on affected Linux hosts, potentially preventing administrators, automation, or orchestration systems from creating, restoring, starting, stopping, or managing instances and storage volumes until the service is restarted or recovered. Because exploitation requires authenticated access with storage-volume creation permissions, the highest risk is in multi-user LXD environments, delegated admin models, CI/CD platforms, hosting platforms, lab environments, and internal platforms where less-trusted users can import or create custom volumes. The issue is not currently listed in CISA KEV, has low EPSS, and has no reported mature public exploit in the provided data, but availability impact is high where LXD is business-critical.

How an attack unfolds

An attacker first obtains valid access to the LXD API, CLI, or another interface that can create custom storage volumes. The account must have `can_create_storage_volumes` or equivalent permissions. The attacker then prepares a custom-volume backup tarball with malformed snapshot metadata, specifically omitting the `expires_at` field expected by LXD. They submit the archive for import as a custom storage volume. When LXD processes the tarball in `CreateCustomVolumeFromBackup`, the missing field triggers a nil-pointer dereference. The daemon crashes or becomes temporarily unavailable, causing denial of service for LXD management operations until the service is restarted and any malformed import state is cleaned up. Repeated submissions can be used to create recurring outages if access is not revoked or patched behavior is not deployed.

How to fix it

Upgrade LXD to a version that contains the vendor fix for this nil-pointer dereference. The description identifies LXD up to versions 6.8 and 5.21 on Linux as affected; deploy the first fixed release newer than those affected branches as provided by the LXD project or your Linux distribution. If an immediate upgrade is not possible, reduce exposure by restricting LXD API and socket access, removing `can_create_storage_volumes` permissions from non-administrative or untrusted users, disabling delegated custom-volume backup imports where feasible, and monitoring for malformed or repeated volume import attempts. Ensure LXD is configured to restart automatically after crashes, but do not treat restart-only recovery as a fix because the same authenticated action can retrigger the issue.

How to confirm the fix worked

Confirm the installed LXD version is not in the affected range by checking `lxc version`, `lxd --version`, package manager metadata, or snap revision information, and compare it against vendor fixed releases. Validate authorization controls by reviewing which users, projects, groups, certificates, or identity mappings have permission to create storage volumes. In a non-production test environment only, verify that malformed custom-volume backup imports are rejected gracefully rather than causing a daemon crash. After remediation, review LXD logs and system service status to confirm there are no recurring crashes, panic messages, or failed custom-volume imports associated with backup restore operations.

Typical attack path

1. Obtain authenticated access to LXD through the API, CLI, socket, or an integrated platform.
2. Confirm the account can create custom storage volumes or import custom-volume backups.
3. Craft a custom-volume backup tarball with snapshot metadata that omits the `expires_at` field.
4. Submit the malicious backup tarball to LXD for custom storage volume creation or import.
5. Trigger `CreateCustomVolumeFromBackup` processing of the malformed archive.
6. Cause a nil-pointer dereference and crash or interrupt the LXD service.
7. Optionally repeat the import attempt to maintain denial of service after service recovery.

How to detect it

Review LXD service logs, systemd journal entries, snap logs, audit logs, reverse proxy logs, and LXD API access logs for evidence of custom storage volume backup imports immediately before LXD crashes or restarts. Focus on authenticated requests that create or import custom volumes, especially requests to storage-pool volume endpoints followed by Go panic messages, nil-pointer dereference errors, abnormal `lxd` process termination, or systemd restart events. Investigate users or certificates that performed volume import operations shortly before availability incidents. On Linux systems using snap packages, review `/var/snap/lxd/common/lxd/logs/lxd.log` and related per-instance logs; on package-based installs, review journal output for the `lxd` service and any distribution-specific LXD logs. Look for repeated attempts, imports of unusual tarballs, failed backup metadata parsing, or references to missing `expires_at` snapshot metadata. Because exploitation requires authentication, correlate events with identity provider, SSH, sudo, auditd, and LXD certificate activity to determine which principal initiated the import.

• panic: runtime error: invalid memory address or nil pointer dereference
• CreateCustomVolumeFromBackup
• expires_at
• custom-volume backup
• backup tarball
• POST /1.0/storage-pools/
• /volumes/custom
• /backups
• lxd.service: Main process exited
• lxd.service: Failed with result
• lxd.service: Scheduled restart job
• /var/snap/lxd/common/lxd/logs/lxd.log
• /var/log/lxd/lxd.log
• lxd crashed
• runtime error: invalid memory address

What your security team should do

• Prioritize patching LXD hosts that support multi-user access, delegated administration, CI/CD workloads, hosted development environments, or exposed LXD APIs.
• Inventory LXD deployments and identify versions at or below 6.8 and 5.21 on Linux until vendor-fixed versions are confirmed deployed.
• Restrict `can_create_storage_volumes` and equivalent permissions to trusted administrators only.
• Review LXD API, Unix socket, and remote certificate access to ensure only authorized users can import or create custom storage volumes.
• Add monitoring for LXD daemon crashes, restarts, panic stack traces, and failed custom-volume backup imports.
• Investigate recent LXD crashes that coincide with storage volume import activity, especially from non-administrative users.
• Where patching is delayed, enforce compensating controls such as API network restrictions, certificate revocation for unnecessary users, and project-level permission tightening.