CVE-2026-28385: Canonical LXD SSRF in Image Import Allows Internal Network Scanning
Canonical LXD has a weakness in how it handles image imports that allows authenticated users to scan internal networks and reach services they shouldn't be able to access. When someone with image-creation permissions requests LXD to import a container image from a URL, the daemon doesn't properly check where that URL points. This means an attacker could probe internal IP ranges, connect to localhost services, or reach cloud metadata endpoints that should be off-limits. The vulnerability requires authentication and specific permissions, which limits exposure, but it's a meaningful network reconnaissance and lateral-movement risk in shared or cloud-hosted LXD environments.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 5.0 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N
- Weaknesses (CWE)
- CWE-918
- Affected products
- 1 configuration(s)
- Published / Modified
- 2026-06-26 / 2026-07-06
NVD description (verbatim)
In Canonical LXD versions 4.12 through 6.9, a Server-Side Request Forgery (SSRF) vulnerability in the image import functionality allows authenticated users with the can_create_images entitlement to interact with internal network infrastructure via the /images endpoint. When importing an image from a URL source, the LXD daemon fails to validate or restrict outbound destination IP addresses, allowing connections to loopback, RFC1918 private ranges, and cloud metadata endpoints. This enables error-based port scanning and unauthorized interaction with internal HTTP services from the daemon's network position.
2 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-28385 is a Server-Side Request Forgery (CWE-918) flaw in LXD's image import endpoint (/images). The daemon accepts image source URLs without validating destination IP addresses, permitting connections to loopback (127.0.0.1/8), RFC1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and cloud metadata services (e.g., 169.254.169.254). Authenticated users holding the can_create_images entitlement can exploit this via error-based port scanning and HTTP interaction with internal services running on the same network segment or within the daemon's access scope. The flaw exists in versions 4.12 through 6.9 of LXD.
Business impact
In production or shared LXD deployments, this vulnerability enables privilege escalation and lateral movement. An insider with container-creation rights can enumerate and interact with internal APIs, management interfaces, or metadata services without needing direct network access. In cloud environments, metadata endpoint access is particularly risky—it could leak credentials or configuration details. The risk is compounded in multi-tenant setups where LXD instances serve different customers or teams, as one tenant's compromise can pivot into shared infrastructure.
Affected systems
Canonical LXD versions 4.12 through 6.9 are vulnerable. Verify your LXD version with `lxd --version`. Systems are only at risk if (1) LXD is running with network exposure (not isolated locally) and (2) users possess the can_create_images entitlement. Environments with strict permission models that restrict image import rights are less exposed, but any LXD instance accepting authenticated connections should be evaluated.
Exploitability
Exploitation requires valid LXD credentials and the can_create_images permission—the attacker cannot be fully unauthenticated. However, the attack is straightforward: craft a POST request to /images with a URL pointing to an internal target, observe error responses or response timing to infer what services exist, and potentially extract data from accessible endpoints. No complex interaction or user action is needed once authenticated. The CVSS score of 5 (Medium) reflects the authentication requirement and information-disclosure-only impact; however, in scenarios where internal services lack additional hardening, the real-world risk may feel higher.
Remediation
Update LXD to a patched version released by Canonical that addresses SSRF validation in the image import endpoint—verify the specific version against the vendor advisory. Organizations unable to patch immediately should restrict the can_create_images entitlement to trusted administrators only, and run LXD in network segments with egress filtering that blocks outbound connections to RFC1918 ranges and loopback addresses. Consider disabling remote image imports entirely if they are not required for your use case.
Patch guidance
Canonical will release a patched version; consult the official Canonical security advisory and LXD release notes for the exact version number and upgrade procedure. LXD typically allows in-place upgrades; test patches in a staging environment first. Prioritize patching any LXD instances in cloud or multi-tenant environments, and verify that image import functionality works as expected post-upgrade.
Detection guidance
Monitor LXD API logs and network activity for image import requests to internal IP ranges. Look for POST requests to /images endpoints with source URLs targeting 127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or 169.254.169.254. Unusual patterns include repeated failed image imports from varying internal addresses (port scanning), or imports initiated by users not normally performing image administration. Network-level detection can flag outbound connections from LXD daemon processes to private or reserved ranges.
Why prioritize this
Prioritize this vulnerability in multi-tenant LXD deployments, cloud environments, and systems where non-admin users hold image-creation rights. In isolated single-user or fully air-gapped LXD instances, risk is lower. The authentication requirement prevents remote, unauthenticated attacks, but the SSRF still enables meaningful reconnaissance and internal service interaction. Given the prevalence of container-based infrastructure, this warrants prompt patching in production environments.
Risk score, explained
The CVSS 3.1 score of 5 (Medium, AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N) reflects: Network-accessible attack vector; low attack complexity (straightforward SSRF); requirement for Low privilege (valid credentials + can_create_images permission); no user interaction needed; scope change (ability to reach services outside the LXD application boundary); confidentiality impact (information disclosure via error messages or direct reads from internal services); and no integrity or availability impact. The score appropriately discounts the authentication barrier but may understate risk in insider-threat or privilege-escalation scenarios.
Frequently asked questions
Can an unauthenticated attacker exploit this?
No. The vulnerability requires valid LXD credentials and the can_create_images entitlement. This significantly limits exposure compared to an unauthenticated SSRF, but insiders or users with delegated image-import rights are at risk.
Does this allow remote code execution?
No. The flaw is limited to Server-Side Request Forgery—the attacker can initiate requests from the LXD daemon's network position and observe responses or errors, but cannot directly execute code. However, if an internal service has command-injection or deserialization flaws, SSRF could be chained to RCE.
How do I know if my LXD is vulnerable?
Check your LXD version with `lxd --version`. If it reports version 4.12 through 6.9, you are vulnerable. Canonical will provide a patched version; watch for the advisory and upgrade. Also audit who has can_create_images permissions in your LXD configuration.
What internal services are most at risk?
Kubernetes API servers, cloud metadata endpoints (like AWS IMDSv1), internal container registries, management dashboards, and any HTTP service on the same network or accessible from the LXD daemon's context. Services without authentication or with weak network segmentation are especially vulnerable.
This analysis is based on the published CVE description and vendor-provided information as of the modification date. Specific patch versions, exact remediation steps, and comprehensive affected-product lists should be verified against Canonical's official security advisory. SEC.co does not guarantee completeness of all impacted configurations or third-party integrations. Organizations should conduct their own risk assessment based on their deployment topology, entitlement model, and network segmentation controls. No proof-of-concept or exploitation code is provided or endorsed. Source: NVD (public-domain), retrieved 2026-08-05. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2025-36324MEDIUMIBM watsonx.data Intelligence SSRF Vulnerability - Patch & Detection Guide
- CVE-2025-58175MEDIUMGeoServer SSRF Vulnerability in Proxy Configuration
- CVE-2026-0285MEDIUMPAN-OS Server-Side Request Forgery (SSRF) – Palo Alto Networks
- CVE-2026-10052MEDIUMQuay SSRF in LDAP/SMTP Validation—Internal Network Reconnaissance Risk
- CVE-2026-10177MEDIUMSSRF in Aider-AI Aider 0.86.3 AWS Metadata Endpoint
- CVE-2026-10239MEDIUMJeecgBoot Server-Side Request Forgery (SSRF) in Word Editing Module
- CVE-2026-10240MEDIUMJeecgBoot SSRF Vulnerability in /airag/airagModel/test Endpoint
- CVE-2026-10241MEDIUMJimuReport SSRF in File Download Function – Patch to 3.9.2