CVE-2026-63300

CVE-2026-63300 is a CVSS 9.9 vulnerability in LXD's project restriction system, and the severity rating is warranted—not because the exploit is technically complex, but because it exposes a fundamental design failure in how LXD enforces multi-tenant isolation. The vulnerability allows an attacker with create-instance permissions on a restricted project to migrate an instance into that project from another project, bypassing the full suite of project restrictions: low-level container options, device access, and network isolation controls. These aren't peripheral constraints—they're the enforcement mechanisms that prevent container escapes, host access, and network boundary violations. An attacker with basic container-creation privileges can effectively land a fully-capable instance inside a security domain that should have excluded them entirely. The root cause is a category error in LXD's permission model: project restrictions are validated at instance creation time, but not during migration. Migration is implicitly trusted as a "move" operation rather than treated as a cross-domain transfer requiring target-state re-validation. This is a common failure pattern in permission systems where developers treat object relocation as a frictionless user action rather than a security boundary that demands independent validation at the destination. The low EPSS score (0.00291) relative to CVSS likely reflects two things: the project restriction feature is underutilized in typical LXD deployments, and the population running multi-tenant LXD environments is smaller but more security-conscious. This doesn't reduce risk—it narrows the exposed population to those most likely to depend on the feature, making the vulnerability more dangerous in the environments where it matters. What should concern you most: the foothold is permanent. Once an instance migrates into a restricted project, there's no subsequent re-validation, no runtime enforcement checking whether it belongs there. If an attacker exploited this before patching, there is no audit trail to detect it—LXD's logging infrastructure likely never considered migration a cross-domain transfer requiring target validation. Immediate actions: patch immediately regardless of your current deployment timeline. Then audit your cross-project operations—instance copy, snapshot restore, and backup restore likely share the same implicit trust model and should be reviewed. If you run LXD as shared infrastructure for Kubernetes workers, CI/CD runners, or multi-tenant hosting, treat this as evidence that your isolation architecture was built on enforced assumptions rather than validated ones.

Reviewed through automated stages and approved by a human before publication.