Column 1
Skip to content
Column 1

Debian LXD DSA-6373-1: Container Host Security Update Checklist

Debian LXD DSA-6373-1 security update checklist for container and virtual machine host administrators

Update August 24, 2026: Canonical published a critical advisory for CVE-2026-66897 in LXD. The advisory describes a container-host boundary risk where a delegated instance-management user could affect host files outside the intended instance boundary. Do not assume the earlier Debian DSA-6373 guidance below covers this separate advisory; check the Canonical notice to determine whether your deployed LXD version and trust model need action.

Prioritize LXD Hosts That Cross Trust Boundaries

  1. Inventory LXD hosts that run customer, agency, CI, development, or other delegated workloads.
  2. Give priority to environments where a tenant, automation account, or delegated administrator can change instance settings, instance templates, or accepted image content.
  3. Until a vendor-supported maintenance decision is in place, limit those capabilities to fully trusted operators and pause intake of unreviewed images where practical.
  4. Use your ordinary access logs and change records to review recent administrative, template, and image-management activity without collecting customer content.

Plan Supported Remediation And Verification

  • Follow the Canonical advisory for the current affected-version and supported remediation guidance. Do not substitute a custom patch or an unverified workaround.
  • Use the existing maintenance, rollback, and customer-communication process for affected hosts. Verify recovery readiness under that normal process; this update does not require a new account backup or a change to backup schedules.
  • After the supported update, confirm normal instance starts, expected storage behavior, tenant isolation, monitoring, and approved administrator access.
  • Keep trust boundaries narrow after maintenance. A software update does not replace ordinary controls on delegated LXD administration and image intake.

Related FixItPhill Guidance

For broader virtual-host planning, review the virtualization hub and the Proxmox resources. Teams coordinating site-owner communication can also start with WordPress support, while container administrators can use the Docker security update guide as a maintenance-planning reference.

Sources For This Update

Debian published DSA-6373-1 for LXD on June 28, 2026. If you run Debian 13 trixie hosts with the Debian lxd package, treat this as a container and virtual machine host maintenance item. The advisory lists multiple LXD issues that can allow security restriction bypasses or arbitrary command execution risk.

This is not a reason to panic-patch blind. LXD sits on a host boundary, so the safe path is to confirm where it is installed, protect the host state, update during a maintenance window, and verify tenant isolation afterward.

What Changed

Debian says the affected package is lxd. For Debian 13 trixie, the fixed package version is 5.0.2+git20231211.1364ae4-9+deb13u7.

The Debian advisory lists these CVEs:

  • CVE-2026-9639
  • CVE-2026-9640
  • CVE-2026-48749
  • CVE-2026-48750
  • CVE-2026-48751
  • CVE-2026-48752
  • CVE-2026-48755
  • CVE-2026-48769
  • CVE-2026-55621
  • CVE-2026-55622

Several of those CVEs overlap with the recent Incus security release coverage, but this Debian advisory is its own action path for Debian-packaged LXD systems.

Who Should Check

  • Debian 13 trixie servers that use LXD for containers or virtual machines.
  • Hosting, agency, SaaS, lab, and MSP environments where LXD hosts run customer, staging, CI, or internal workloads.
  • Admin workstations or automation nodes that manage LXD remotes or trusted clients.
  • Backup, image, or migration systems that interact with LXD instances.

Safe Maintenance Path

  1. Inventory LXD hosts first. Confirm which Debian systems actually have the Debian lxd package installed and whether they expose an API, run remote clients, or host tenant workloads.
  2. Protect the current state. Take host-level backups or snapshots where practical, confirm recent container and VM backups, and make sure you can restore at least one representative workload before changing production hosts.
  3. Plan tenant impact. If the host serves customers, schedule a maintenance window, drain workloads where your environment supports it, and warn customers if restart or migration work may briefly affect service.
  4. Apply the Debian security update. Use your normal Debian security update workflow, managed patching platform, or hosting automation. The target fixed version for trixie is 5.0.2+git20231211.1364ae4-9+deb13u7 or newer.
  5. Verify isolation after the update. Review restricted projects, profiles, storage pools, image sources, trusted client access, backup import/export paths, and cross-project copy behavior.
  6. Check post-change health. Confirm containers and VMs start normally, network profiles still behave as expected, storage mounts are intact, backups still complete, and logs do not show unexpected permission or profile errors.

Attack Status

The Debian advisory does not state that these LXD issues are being actively exploited. This Fix I.T. Phill radar pass also did not find a newer CISA Known Exploited Vulnerabilities catalog entry for this LXD advisory. The risk still matters because container and VM managers sit close to host and tenant isolation boundaries.

Hosting Notes

If LXD is part of a hosting or customer platform, separate three pieces of work: package patching, tenant-boundary verification, and customer communication. Do not assume the package update alone proves every isolation control is still configured correctly. Review the host access model, remote API exposure, admin workstation access, backup handling, and image intake process as part of the same maintenance window.

If you also run Incus, read the related Fix I.T. Phill checklist: Incus 7.2 Security Update: Host and Tenant Isolation Checklist.

Official Sources