CVE-2026-66898
CVE-2026-66898 is a path traversal vulnerability in LXD's backup import functionality. When you restore a container from an exported archive, LXD parses metadata embedded in that archive — and the code that handles those parsed values constructs filesystem paths without validating that they stay within the intended restore directory. An attacker who can supply a crafted LXD archive can break out of the restore sandbox and write files to arbitrary locations on the LXD host. The CVSS 9.9 reflects the severity: if you have the ability to trigger a backup restore, this flaw can give you filesystem write access beyond the container's storage pool. What makes this worth your attention isn't just the score — it's the pattern. LXD's backup functionality was designed for operators moving instances between their own nodes or recovering from backups they created. The developers assumed that since they control archive generation, the metadata inside those archives is inherently trusted. That's a reasonable design assumption under normal operational conditions that collapses completely when an external actor supplies the archive. This exact pattern — trusting serialized metadata from exported artifacts — has appeared repeatedly in container ecosystems and beyond. It is, fundamentally, an insecure deserialization vulnerability wearing different clothing. The practical question is who can actually trigger this. LXD's backup operations require privileged access — you need to be the LXD admin or have the ability to invoke lxc import. In single-admin deployments, this limits the realistic attack surface. But pay attention to the non-human paths: CI/CD pipelines running lxc import, infrastructure-as-code tools automating restores, GitOps workflows pulling archives from object storage. These automation chains inherit the privileged operator's trust model without the operator's situational awareness. If your backup restore pipeline pulls from a source an attacker could influence — even indirectly — the privilege barrier becomes irrelevant. For immediate action: verify that any LXD restore operations in your environment validate the source of the archive. Treat all imported archives as untrusted input regardless of where they originated. Check that your CI/CD and IaC tooling doesn't automatically restore archives from untrusted locations. If you're running multi-tenant LXD hosts, this vulnerability has the potential to affect isolation between customers through storage backend collisions — prioritize patching there. The patch addresses the path validation gap directly, but the deeper lesson is that backup formats are bridge interfaces between systems and should never assume benign origins just because they were originally designed for trusted internal use.
Reviewed through automated stages and approved by a human before publication.