---
id: "CVE-2026-28385"
page: "https://infrastack.ai/live/CVE-2026-28385"
kind: "vulnerability"
aliases: ["CVE-2026-28385", "GHSA-3gq2-x4qg-p4g6"]
title: "LXD: SSRF via image import from URL allows internal network probing by authenticated users"
severity: "medium"
cvss: 5.0
epss: 0.00278
exploited: false
status: "open"
category: "runtime"
products: [{"name": "github.com/canonical/lxd", "fixed": ["0.0.0-20261005133302-c4a919f3f4e2"], "affected": "< 0.0.0-20261005133302-c4a919f3f4e2", "ecosystem": "go"}, {"name": "canonical lxd", "fixed": [], "affected": ">= 4.12, <= 6.9", "ecosystem": "vendor"}]
ecosystems: ["go", "vendor"]
tags: ["cwe-918", "linux-containers", "lxd", "runtime", "self-hosted"]
not_affected_if: ["admin-only-image-creation"]
published_at: "2026-06-26T17:16:32+00:00"
first_seen_at: "2026-11-06T18:31:37+00:00"
updated_at: "2026-11-06T18:44:09+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-3gq2-x4qg-p4g6", "first_seen_at": "2026-11-06T18:31:37+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28385", "first_seen_at": "2026-11-06T18:44:09+00:00"}]
exploit_sources: [{"type": "epss", "score": 0.00278, "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-28385"}]
---

# LXD: SSRF via image import from URL allows internal network probing by authenticated users

Link for people: https://infrastack.ai/live/CVE-2026-28385 (this .md is for agents)

LXD's image import-from-URL endpoint makes server-side requests to any user-supplied address, including loopback, private ranges and cloud metadata endpoints, without checks. An authenticated user with the image-creation permission can use the error messages to map open ports on internal networks reachable from the LXD host.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- go:github.com/canonical/lxd affected < 0.0.0-20261005133302-c4a919f3f4e2 fixed 0.0.0-20261005133302-c4a919f3f4e2
- vendor:canonical lxd affected >= 4.12, <= 6.9 fixed no fixed version listed

## How to check

- Check the installed LXD version against the `go:github.com/canonical/lxd` range in the advisory (affected before `0.0.0-20261005133302-c4a919f3f4e2`).
- Find out which accounts hold the `can_create_images` entitlement; unknown whether the sources list a specific command for this.

## Fix

- Upgrade LXD to `0.0.0-20261005133302-c4a919f3f4e2` or later, per the product ranges.

## Timeline

- 2026-11-06T18:31:37+00:00 ghsa https://github.com/advisories/GHSA-3gq2-x4qg-p4g6
- 2026-11-06T18:44:09+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-28385

## Documents

- [advisory] Maintainer's advisory: api.github.com https://api.github.com/repos/canonical/lxd/security-advisories/GHSA-3gq2-x4qg-p4g6
- [advisory] Maintainer's advisory: github.com https://github.com/canonical/lxd/security/advisories/GHSA-3gq2-x4qg-p4g6
- [fix] Patch: github.com https://github.com/canonical/lxd/pull/18210
- [fix] Patch: github.com https://github.com/canonical/lxd/pull/18462
- [fix] Patch: github.com https://github.com/canonical/lxd/commit/08996fa031eebc2bc2f8e27148c2ba24386c01d0
- [fix] Patch: github.com https://github.com/canonical/lxd/commit/4bbdb17ab67010446668e4b00a5175df5b6d55b4
- [fix] Patch: github.com https://github.com/canonical/lxd/commit/5976c92117b79d73437d7fab55e34cb80083edff
- [fix] Patch: github.com https://github.com/canonical/lxd/commit/886fcf5b7686bf59de78e239cec90a69e8fb9c65
- [fix] Patch: github.com https://github.com/canonical/lxd/commit/c4a919f3f4e21249d535d4030a33484313026111
- [fix] Release: github.com https://github.com/canonical/lxd/releases/tag/lxd-6.9

## From the sources

## Summary
The LXD image import-from-URL endpoint (`POST /1.0/images` with `source.type=url`) makes server-side HTTP requests to an attacker-supplied URL without any private-IP or loopback blocking. An authenticated user with the `can_create_images` entitlement can force the LXD daemon to connect to internal network addresses (127.0.0.1, RFC1918 ranges, cloud metadata endpoints), enabling port scanning via error-based inference and interaction with internal HTTP services from the daemon's privileged network position.

## Severity

- **Attack Vector:** Network — LXD API is network-accessible.
- **Attack Complexity:** Low — Single crafted API request with no special conditions.
- **Privileges Required:** Low — Requires `can_create_images` entitlement, a non-admin permission commonly delegated to regular users.
- **User Interaction:** None.
- **Scope:** Changed — The attacker leverages LXD's privileged network position to probe and interact with internal services that are outside the attacker's direct network access and outside the scope of LXD's image management authorization.
- **Confidentiality Impact:** Low — Error messages reveal internal port states (open/closed/filtered) and service availability. Response bodies from internal services are NOT returned to the attacker (hash validation blocks content exfiltration).
- **Integrity Impact:** None — No demonstrated ability to modify data on internal services.
- **Availability Impact:** None — No meaningful resource exhaustion or denial of service.

## Affected Component
- `lxd/images.go` — `imgPostURLInfo` (lines 668–755) — Makes HEAD request to user-supplied URL without any SSRF protections.
- `lxd/util/http.go` — `HTTPClient` (lines 102–147) — Creates HTTP client with no IP blocking or URL validation.
- `shared/network.go` — `RFC3493Dialer` (lines 20–49) — Dials arbitrary hosts including private/loopback ranges.
- `lxd/daemon_images.go` — `ImageDownload` (lines 478–510, "direct" case) — Makes GET request to URL from attacker-controlled response header.

## Description

### Core vulnerability: no SSRF protections on server-side image fetching

When a user imports an image from a URL, the `imgPostURLInfo` function makes an HTTP HEAD request directly to the user-supplied URL with zero validation:

```go
// lxd/images.go:668-703
func imgPostURLInfo(ctx context.Context, s *state.State, req api.ImagesPost, ...) (*api.Image, error) {
    if req.Source.URL == "" {
        return nil, errors.New("Missing URL")
    }

    myhttp, err := util.HTTPClient("", s.Proxy)
    // ...

    // Resolve the image URL
    head, err := http.NewRequest("HEAD", req.Source.URL, nil)
    // No URL validation, no scheme check, no IP range check
    // ...

    raw, err := myhttp.Do(head)  // Makes request to arbitrary destination
```

The HTTP client is created via `util.HTTPClient` which uses `shared.RFC3493Dialer` — a standard dialer with zero private-IP filtering:

```go
// shared/network.go:20-49
func RFC3493Dialer(context context.Context, network string, address string) (net.Conn, error) {
    host, port, err := net.SplitHostPort(address)
    // ...
    addrs, err := net.LookupHost(host)
    // ...
    for _, a := range addrs {
        c, err := net.DialTimeout(network, net.JoinHostPort(a, port), 10*time.Second)
        // No check: IsLoopback? IsPrivate? IsLinkLocalUnicast?
        // Connects to ANY resolved address including 127.0.0.1, 10.x.x.x, 169.254.169.254
```

The HTTP client also follows redirects unconditionally:

```go
// lxd/util/http.go:139-144
myhttp.CheckRedirect = func(req *http.Request, via []*http.Request) error {
    // Replicate the headers
    req.Header = via[len(via)-1].Header
    return nil  // Always follows redirects — no destination validation
}
```

### No SSRF protections exist anywhere in the codebase

An exhaustive search for private-IP checks (`IsLoopback`, `IsPrivate`, `IsLinkLocalUnicast`), URL allowlists, or SSRF-specific protections found **zero results** in any HTTP client or outbound request path. The codebase has no SSRF defense infrastructure.

### Chained SSRF via `LXD-Image-URL` response header

After the HEAD request, the `LXD-Image-URL` response header is used as the target for a second HTTP GET request, creating a chained SSRF:

```go
// lxd/images.go:705-725
hash := raw.Header.Get("LXD-Image-Hash")  // Attacker controls this
url := raw.Header.Get("LXD-Image-URL")    // Attacker controls this

info, err := ImageDownload(ctx, s, op, &ImageDownloadArgs{
    Server:   url,       // Attacker-controlled URL from response header
    Protocol: "direct",  // Forces unprotected direct HTTP GET
    Alias:    hash,      // Attacker-controlled hash
    // ...
})
```

In `ImageDownload`, the "direct" case makes a GET to the attacker-controlled URL:

```go
// lxd/daemon_images.go:478-510
case "direct":
    httpClient, err := util.HTTPClient(args.Certificate, s.Proxy)
    // ...
    req, err := http.NewRequest(http.MethodGet, args.Server, nil)  // args.Server = attacker URL
    // ...
    raw, doneCh, err := cancel.CancelableDownload(canceler, httpClient.Do, req)
```

This means an attacker who controls the HEAD target can redirect the second GET request to any internal service. The response body is downloaded to disk but hash validation prevents the attacker from reading it:

```go
// lxd/daemon_images.go:541-544
result := hex.EncodeToString(sha256.Sum(nil))
if result != fp {
    return nil, fmt.Errorf("Hash mismatch for %q: %s != %s", args.Server, result, fp)
}
```

### Error observability enables port scanning

Errors from the outbound request propagate back to the caller via the operation result:

```go
// lxd/operations/operations.go:612-614
if op.err != nil {
    retOp.Err = response.SmartError(op.err).String()
}
```

The error messages differ based on the target's state:
- **Port open**: `"Missing LXD-Image-Hash header"` (HEAD succeeded, response had no expected headers)
- **Port closed**: `"connection refused"` (connection rejected immediately)
- **Port filtered/host unreachable**: `"context deadline exceeded"` / `"no route to host"` (timeout or routing error)

These differences allow systematic port scanning of internal networks from the LXD daemon's network position.

### Execution chain

1. Attacker sends `POST /1.0/images` with `{"source":{"type":"url","url":"http://127.0.0.1:6379/"}}`
2. `imagesPost` handler verifies `can_create_images` entitlement (line 1163)
3. Background operation calls `imgPostURLInfo` (line 1361)
4. `imgPostURLInfo` creates HTTP client via `util.HTTPClient` — no SSRF protections (line 675)
5. HEAD request to `http://127.0.0.1:6379/` — no IP validation (line 700)
6. `RFC3493Dialer` resolves `127.0.0.1` and dials it — no private-IP check (line 33)
7. Error or response propagated back via operation (line 612-614 in operations.go)
8. Attacker queries operation result via `GET /1.0/operations/{id}/wait` and reads the error message

For chained SSRF:
1. Attacker points `source.url` to their own server
2. Their server responds with `LXD-Image-Hash: <any>` and `LXD-Image-URL: http://169.254.169.254/latest/meta-data/`
3. LXD makes GET to `http://169.254.169.254/...` (line 493 in daemon_images.go)
4. Response body downloaded but hash validation prevents content exfiltration
5. Error messages still reveal whether the internal service responded (200 vs error)

## Proof of Concept

```bash
# Safe PoC: force daemon to connect to loopback port 1 (closed port).
# Error message will confirm server-side request occurred.
SOCK=/var/lib/lxd/unix.socket

# Create the operation
OP=$(curl -s --unix-socket "$SOCK" \
  -H 'Content-Type: application/json' \
  -X POST http://localhost/1.0/images \
  -d '{"source":{"type":"url","url":"http://127.0.0.1:1/"}}' \
  | sed -n 's/.*"operation":"\([^"]*\)".*/\1/p')

# Wait for result — expect "connection refused" confirming SSRF
curl -s --unix-socket "$SOCK" "http://localhost${OP}/wait"
# Response will contain error with "connection refused"

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_