CVE-2026-28384: Canonical LXD Authenticated RCE via Compression

CVE-2026-28384 is a command injection flaw in Canonical LXD. An authenticated, unprivileged user can run commands as the LXD daemon through the image and backup API endpoints. NVD scores it 9.9. Fixed snap versions are 5.0.6-e49d9f4, 5.21.4-1374f39 and 6.7-1f11451, so refresh your LXD snap.

What's affected

Canonical's announcement and the NVD record agree on the scope. The flaw affected LXD from 4.12 through 6.6. Canonical adds that the bug exists from 2.12 but is only considered a security issue from 4.12, because earlier versions gave any user with LXD access full control of the daemon. The restricted project feature, introduced in 4.12, is what created a boundary that this bug crosses.

The fixed snap versions are:

• Channel 5.0/stable: 5.0.6-e49d9f4
• Channel 5.21/stable: 5.21.4-1374f39
• Channel 6 (6.0): 6.7-1f11451
• Channel 4.0/stable: not affected, since it is version 4.0.10 and has no restricted projects

Ubuntu archive packages for Xenial, Bionic and Focal are also not affected, for the same reason.

The vector is network, low complexity, low privileges required, scope changed, giving 9.9. The attacker needs valid LXD credentials. The weakness is CWE-78 (OS Command Injection).

How to check if you're exposed

Canonical's own instruction is to list the snap and compare the channel and revision with their table.

snap list | grep lxd

If you run LXD from the Ubuntu archive or another package source, check which version it provides and whether it is 4.12 or later.

Then work out who holds LXD credentials. Any user, certificate or token that can call the LXD API to export images or create backups is a potential entry point, including accounts in restricted projects that were meant to be confined.

What to do now

1. Refresh the LXD snap with the command below, then confirm the channel and revision against Canonical's table.
2. On clustered hosts, update every member and verify each one.
3. Review which users, certificates and trust tokens have access to LXD, and remove any that are not needed.
4. Treat restricted projects as a boundary that was weak until you patched. Review activity from restricted-project users since the introduction of the affected version if you host untrusted tenants.
5. Check your LXD hosts for unexpected processes or files if untrusted users had API access.

Why it matters

The cause is CWE-78 (Improper Neutralization of Special Elements used in an OS Command). Canonical explains that the backup and image endpoints accept a compression algorithm as a way to export images. The parser took the user supplied value without proper validation, and the backend then built a command from it. A value that should have named an algorithm could instead name a program.

This is a privilege boundary problem, not an internet-facing one. The attacker already needs credentials. What the bug gives them is the daemon's power, which on an LXD host is the power to manage every container and virtual machine and, typically, to act as root on the host. For shared hosts that run workloads for several teams or customers, that turns a low privilege account into full control.

The scope changed rating in the CVSS vector captures this. The vulnerable component is the API, and the impact is on the host and everything the daemon controls.

The record does not flag exploitation in the wild, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog. Canonical credits an outside reporter and published fixes on 11 March 2026, a day before the announcement, so patches have been available for some time.

Quick check

Sources

• Canonical announcement: LXD authenticated remote code execution fixes available
• GitHub Security Advisory GHSA-4rmf-rcp8-2r9g

Last reviewed: 19 October 2026.