CVE-2026-41684: Github.com/lxc/incus/v6/cmd/incusd Incus Has Nil Dereferences On Vulnerability

MODERATE
Advisory Identifier: GHSA-x5r6-jr56-89pv
CVSS 6.5
CWE-476
Published
Advisory Summary

CVE-2026-41684 is a MODERATE (CVSS 6.5) incus has nil dereferences on vulnerability (CWE-476: NULL Pointer Dereference) affecting Github.com/lxc/incus/v6/cmd/incusd libraries in the Go ecosystem. The issue involves incus has nil dereferences on restore via malformed yaml. Remediation is available in the latest vendor maintenance releases.

CVE-2026-41684 at a Glance

CVE Identifier CVE-2026-41684
GHSA Identifier GHSA-x5r6-jr56-89pv
Severity MODERATE
CVSS v3.1 Base Score 6.5
CWE Classification CWE-476: NULL Pointer Dereference
Affected Product Github.com/lxc/incus/v6/cmd/incusd
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 6.5

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:H).

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 High (A:H)

How to Fix CVE-2026-41684

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-41684, 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-476: NULL Pointer Dereference, where the product dereferences a pointer that it expects to be valid but is null. 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 ### Details It was found that backup.GetInfo() trusts the inline backup/index.yaml config when present and only falls back to parsing the legacy backup/container/backup.yaml file if result.Config == nil. As a result, an archive can carry a valid inline config that passes the initial import preflight while also carrying a malformed legacy backup/container/backup.yaml file that is reparsed later from the restored file system. ParseConfigYamlFile() accepts YAML documents with no container section, and multiple downstream consumers then dereference .Container without checking for nil. Confirmed examples in the instance restore and import flow include backup.UpdateInstanceConfig() and internalImportFromBackup(). An authenticated user with permission to import instance backups may be able to crash the Incus daemon with a crafted backup archive whose inline backup/index.yaml is valid but whose extracted legacy backup.yaml omits container. The crash occurs in the restore path after archive extraction has begun. The flow is as follows: A crafted backup archive contains a valid backup/index.yaml file together with a malformed backup/container/backup.yaml file that omits the container section. backup.GetInfo() parses backup/index.yaml successfully, so bInfo.Config is populated from the inline config. Because result.Config != nil, GetInfo() does not fall back to backup/container/backup.yaml. instances_post.go then builds the request from bInfo.Config.Container, which succeeds because the inline config is valid. Later, storage unpack extracts backup/container/backup.yaml into the instance volume as <mountPath>/backup.yaml. backend.go then calls backup.UpdateInstanceConfig(..., mountPath), which reparses <mountPath>/backup.yaml through ParseConfigYamlFile(). Because ParseConfigYamlFile() accepts YAML with no container section, backup.Container == nil, and later access to backup.Container.Devices or backup.Container.ExpandedDevices can trigger a nil-pointer dereference. Affected Files: - https://github.com/lxc/incus/blob/v6.22.0/internal/server/backup/backup_info.go#L87 - https://github.com/lxc/incus/blob/v6.22.0/internal/server/backup/backup_info.go#L115 - https://github.com/lxc/incus/blob/v6.22.0/internal/server/backup/backup_config_utils.go#L85 - https://github.com/lxc/incus/blob/v6.22.0/internal/server/backup/backup_config_utils.go#L159 - https://github.com/lxc/incus/blob/v6.22.0/internal/server/storage/backend.go#L809 - https://github.com/lxc/incus/blob/v6.22.0/cmd/incusd/api_internal.go#L749 The initial backup-metadata parser prefers inline backup/index.yaml content: Affected Code: ``` if hdr.Name == backupIndexPath { err = yaml.NewDecoder(tr).Decode(&result) ``` The legacy backup/container/backup.yaml file is only parsed if the inline config is absent: Affected Code: ``` if result.Config == nil && hdr.Name == "backup/container/backup.yaml" { err = yaml.NewDecoder(tr).Decode(&result.Config) ``` ParseConfigYamlFile() accepts an empty YAML document, or one with no container section, without validation: Affected Code: ``` func ParseConfigYamlFile(path string) (*config.Config, error) { data, err := os.ReadFile(path) ... backupConf := config.Config{} err = yaml.Unmarshal(data, &backupConf) ``` UpdateInstanceConfig() conditionally uses backup.Container at first but later dereferences it unconditionally: Affected Code: ``` if backup.Container != nil { backup.Container.Name = b.Name backup.Container.Project = b.Project } if updateRootDevicePool(backup.Container.Devices, pool.Name) { rootDiskDeviceFound = true } if updateRootDevicePool(backup.Container.ExpandedDevices, pool.Name) { rootDiskDeviceFound = true } ``` Another confirmed sink is present in internalImportFromBackup(): Affected Code: ``` if allowNameOverride { backupConf.Container.Name = instName } if instName != backupConf.Container.Name { return fmt.Errorf("Instance name requested %q doesn't match instance name in backup config %q", instName, backupConf.Container.Name) } ``` This was confirmed as follows: Command: ``` go test ./test/fuzz -run='TestExtractedBackupYAMLMissingContainerNilDereference' -count=1 -v ``` Output: ``` === RUN TestExtractedBackupYAMLMissingContainerNilDereference === RUN TestExtractedBackupYAMLMissingContainerNilDereference/legacy_backup_empty extracted_backup_yaml_poc_test.go:70: UpdateInstanceConfig panicked on malformed extracted backup.yaml (container is nil): runtime error: invalid memory address or nil pointer dereference === RUN TestExtractedBackupYAMLMissingContainerNilDereference/legacy_backup_pool_only extracted_backup_yaml_poc_test.go:70: UpdateInstanceConfig panicked on malformed extracted backup.yaml (container is nil): runtime error: invalid memory address or nil pointer dereference === RUN TestExtractedBackupYAMLMissingContainerNilDereference/legacy_backup_volume_only extracted_backup_yaml_poc_test.go:70: UpdateInstanceConfig panicked on malformed extracted backup.yaml (container is nil): runtime error: invalid memory address or nil pointer dereference --- FAIL: TestExtractedBackupYAMLMissingContainerNilDereference (0.21s) FAIL ``` It is recommended to validate the parsed legacy backup.yaml structure before any dereference and to fail with a standard error if Container is missing: Proposed Fix: ``` if backup.Container == nil { return errors.New("No container struct in the backup file found") } ``` That validation should be added at minimum in: backup.UpdateInstanceConfig() and internalImportFromBackup() before any backupConf.Container.* access More broadly, it is recommended to centralize backup-config validation so that both inline backup/index.yaml and extracted legacy backup.yaml files are checked against the same structural requirements before any restore or import consumer uses them. 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-41684 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-41684?
CVE-2026-41684 is a security vulnerability in Github.com/lxc/incus/v6/cmd/incusd involving Incus has Nil Dereferences on Restore via Malformed YAML under CWE-476: NULL Pointer Dereference.
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-41684?
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-41684?
CVE-2026-41684 has a CVSS v3.1 base score of 6.5 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H.
What CWE is associated with CVE-2026-41684?
CVE-2026-41684 is classified under CWE-476: NULL Pointer Dereference (The product dereferences a pointer that it expects to be valid but is NULL.).
How can I check Go dependencies for CVE-2026-41684?
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-x5r6-jr56-89pv",
  "modified" : "2026-05-08T21:47:19Z",
  "published" : "2026-05-04T19:45:23Z",
  "aliases" : [ "CVE-2026-41684" ],
  "summary" : "Incus has Nil Dereferences on Restore via Malformed YAML",
  "details" : "### Summary\n\n### Details\nIt was found that backup.GetInfo() trusts the inline backup/index.yaml config when present and only falls back to parsing the legacy backup/container/backup.yaml file if result.Config == nil. As a result, an archive can carry a valid inline config that passes the initial import preflight while also carrying a malformed legacy backup/container/backup.yaml file that is reparsed later from the restored file system.\n\nParseConfigYamlFile() accepts YAML documents with no container section, and multiple downstream consumers then dereference .Container without checking for nil. Confirmed examples in the instance restore and import flow include backup.UpdateInstanceConfig() and internalImportFromBackup().\n\nAn authenticated user with permission to import instance backups may be able to crash the Incus daemon with a crafted backup archive whose inline backup/index.yaml is valid but whose extracted legacy backup.yaml omits container. The crash occurs in the restore path after archive extraction has begun.\n\nThe flow is as follows:\nA crafted backup archive contains a valid backup/index.yaml file together with a malformed backup/container/backup.yaml file that omits the container section.\nbackup.GetInfo() parses backup/index.yaml successfully, so bInfo.Config is populated from the inline config.\nBecause result.Config != nil, GetInfo() does not fall back to backup/container/backup.yaml.\ninstances_post.go then builds the request from bInfo.Config.Container, which succeeds because the inline config is valid.\nLater, storage unpack extracts backup/container/backup.yaml into the instance volume as <mountPath>/backup.yaml.\nbackend.go then calls backup.UpdateInstanceConfig(..., mountPath), which reparses <mountPath>/backup.yaml through ParseConfigYamlFile().\nBecause ParseConfigYamlFile() accepts YAML with no container section, backup.Container == nil, and later access to backup.Container.Devices or backup.Container.ExpandedDevices can trigger a nil-pointer dereference.\n\n\nAffected Files:\n - https://github.com/lxc/incus/blob/v6.22.0/internal/server/backup/backup_info.go#L87\n - https://github.com/lxc/incus/blob/v6.22.0/internal/server/backup/backup_info.go#L115\n - https://github.com/lxc/incus/blob/v6.22.0/internal/server/backup/backup_config_utils.go#L85\n - https://github.com/lxc/incus/blob/v6.22.0/internal/server/backup/backup_config_utils.go#L159\n - https://github.com/lxc/incus/blob/v6.22.0/internal/server/storage/backend.go#L809\n - https://github.com/lxc/incus/blob/v6.22.0/cmd/incusd/api_internal.go#L749\n\nThe initial backup-metadata parser prefers inline backup/index.yaml content:\n\nAffected Code:\n```\nif hdr.Name == backupIndexPath {\n    err = yaml.NewDecoder(tr).Decode(&result)\n```\n\nThe legacy backup/container/backup.yaml file is only parsed if the inline config is absent:\n\nAffected Code:\n```\nif result.Config == nil && hdr.Name == \"backup/container/backup.yaml\" {\n    err = yaml.NewDecoder(tr).Decode(&result.Config)\n```\n\nParseConfigYamlFile() accepts an empty YAML document, or one with no container section, without validation:\n\nAffected Code:\n```\nfunc ParseConfigYamlFile(path string) (*config.Config, error) {\n    data, err := os.ReadFile(path)\n    ...\n    backupConf := config.Config{}\n    err = yaml.Unmarshal(data, &backupConf)\n```\n\nUpdateInstanceConfig() conditionally uses backup.Container at first but later dereferences it unconditionally:\n\nAffected Code:\n```\nif backup.Container != nil {\n    backup.Container.Name = b.Name\n    backup.Container.Project = b.Project\n}\n\nif updateRootDevicePool(backup.Container.Devices, pool.Name) {\n    rootDiskDeviceFound = true\n}\n\nif updateRootDevicePool(backup.Container.ExpandedDevices, pool.Name) {\n    rootDiskDeviceFound = true\n}\n```\n\nAnother confirmed sink is present in internalImportFromBackup():\n\nAffected Code:\n```\nif allowNameOverride {\n    backupConf.Container.Name = instName\n}\n\nif instName != backupConf.Container.Name {\n    return fmt.Errorf(\"Instance name requested %q doesn't match instance name in backup config %q\", instName, backupConf.Container.Name)\n}\n```\n\nThis was confirmed as follows:\n\nCommand:\n```\ngo test ./test/fuzz -run='TestExtractedBackupYAMLMissingContainerNilDereference' -count=1 -v\n```\n\nOutput:\n\n```\n=== RUN   TestExtractedBackupYAMLMissingContainerNilDereference\n=== RUN   TestExtractedBackupYAMLMissingContainerNilDereference/legacy_backup_empty\n   extracted_backup_yaml_poc_test.go:70: UpdateInstanceConfig panicked on malformed extracted\n       backup.yaml (container is nil): runtime error: invalid memory address or nil pointer\n       dereference\n=== RUN   TestExtractedBackupYAMLMissingContainerNilDereference/legacy_backup_pool_only\n   extracted_backup_yaml_poc_test.go:70: UpdateInstanceConfig panicked on malformed extracted\n       backup.yaml (container is nil): runtime error: invalid memory address or nil pointer\n       dereference\n=== RUN   TestExtractedBackupYAMLMissingContainerNilDereference/legacy_backup_volume_only\n   extracted_backup_yaml_poc_test.go:70: UpdateInstanceConfig panicked on malformed extracted\n       backup.yaml (container is nil): runtime error: invalid memory address or nil pointer\n       dereference\n--- FAIL: TestExtractedBackupYAMLMissingContainerNilDereference (0.21s)\nFAIL\n```\n\nIt is recommended to validate the parsed legacy backup.yaml structure before any dereference and to fail with a standard error if Container is missing:\n\nProposed Fix:\n```\nif backup.Container == nil {\n    return errors.New(\"No container struct in the backup file found\")\n}\n```\n\nThat validation should be added at minimum in: backup.UpdateInstanceConfig() and internalImportFromBackup() before any backupConf.Container.* access\n\nMore broadly, it is recommended to centralize backup-config validation so that both inline backup/index.yaml and extracted legacy backup.yaml files are checked against the same structural requirements before any restore or import consumer uses them.\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:H"
  } ],
  "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-x5r6-jr56-89pv"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-41684"
  }, {
    "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-476" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-04T19:45:23Z",
    "nvd_published_at" : "2026-05-07T14:16:03Z"
  }
}