External risk intelligence

LXD Command Injection via API Parameter

CVE advisorySeverity: CRITICAL (CVSS 9.4)

CVE-2026-28384

LXD is a system container manager typically deployed in internal infrastructure or as part of a management plane. While the API can be network-reachable, it is generally intended for administrative use within trusted networks rather than public internet exposure, making widespread direct internet-facing deployment uncommon.

OS Command Injection

Canonical Lxd

4.12 to before 5.0.65.21.0 to before 5.21.46.0 to before 6.7

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This vulnerability in Canonical LXD allows an authenticated user to execute commands on the server, potentially impacting the integrity and availability of systems running LXD. The concern centers on understanding if and where LXD is deployed within our environment and the potential for unauthorized command execution.

Issue: Authenticated users can run commands as the server.
Why remember: Could affect critical container management systems.
Executive takeaway: Confirm relevance and exposure within our LXD usage.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this vulnerability by first gaining unprivileged access to the LXD system. From there, they can send specially crafted API requests to the image and backup endpoints, targeting the compression algorithm parameter. Successful exploitation allows the attacker to execute arbitrary commands with the privileges of the LXD daemon on the server.

Requires authenticated, unprivileged access.
Triggers via API calls to image/backup endpoints.
Risks command execution as LXD daemon.

Live Threat

Current exploitation, exposure, and threat context

An authenticated, unprivileged user could execute arbitrary commands on the LXD server as the LXD daemon. This is possible by sending specially crafted API calls to the image and backup endpoints.

LXD server commands could be affected.
Malicious API calls could trigger execution.
Server compromise or unauthorized actions may occur.

Operational Fix

Recommended remediation, mitigation, and detection steps

Given that LXD is a system container manager, the platform team or infrastructure team likely manages its deployment. The first practical step is to identify all LXD instances within your environment, determine their exposure, and ascertain which are business-critical to prioritize remediation efforts. Coordination with Canonical, the vendor, may be necessary for timely updates or mitigation strategies.

Identify LXD instances and their criticality.
Verify network reachability and asset ownership.
Plan remediation based on risk and vendor coordination.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Canonical LXD and how is it used?

Canonical LXD is a system container manager used to run and manage full Linux systems within lightweight containers. It acts as an abstraction layer over low-level container technologies, providing a REST API that developers and administrators use to control container life cycles, images, and backups. It is widely used in server environments to isolate workloads efficiently.

What does CWE-78 mean in the context of CVE-2026-28384?

CWE-78 refers to Improper Neutralization of Special Elements used in an OS Command, commonly known as OS Command Injection. In this CVE, the vulnerability occurs because the LXD software does not properly sanitize a specific input parameter related to compression algorithms. Because the application processes this input without enough safety checks, an attacker can append their own system commands, which the server then executes with administrative privileges.

How is this vulnerability triggered?

An attacker triggers this flaw by sending a maliciously crafted API request to the image or backup management endpoints in LXD. For the attack to succeed, the user must already possess authenticated, unprivileged access to the LXD system. It is important to note that actions taken by an unauthenticated user or requests that do not involve the vulnerable compression algorithm parameter will not trigger this command injection bug.

Is my system at risk?

While any system running the affected versions is theoretically vulnerable, Halo Surface Signal notes that LXD is typically deployed within internal infrastructure or management planes. Because it is generally intended for administrative use in trusted networks rather than public internet exposure, widespread direct internet-facing usage is uncommon. You should evaluate whether your LXD API is accessible to untrusted users or network segments.

What should I do if I am running LXD?

The most effective first step is to perform an inventory of all LXD instances in your environment to identify versions currently in use. Once you have identified these assets, focus on upgrading to the patched snap versions provided by Canonical, such as 5.0.6, 5.21.4, or 6.7, which specifically address this flaw. Prioritize remediation for instances that manage critical infrastructure or have higher network accessibility.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.