CVE-2026-41647: Incusd · Incus has Nil-Pointer Dereference via S3 Bucket Import
Affects github.com/lxc/incus/v6/cmd/incusdSource GCVE Database
Not known to be exploited · CVSS 6.5 Medium.
Data as of 27 Oct 2026, 00:07 UTC
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 7 May 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| Gogithub.com/lxc/incus/v6/cmd/incusd | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
### Summary Missing error handling could lead an authenticated Incus user to cause a daemon crash through the import of a truncated storage bucket backup file. ### Details It was found that TransferManager.UploadAllFiles iterates over tar entries but only checks for io.EOF from tr.Next(). When tr.Next() returns a non-EOF error, such as unexpected EOF from a truncated archive, the header hdr is nil and the code continues to access hdr.Name, causing a nil-pointer dereference that panics the daemon. This may allow the Incus daemon to be crashed during S3 bucket restore if a truncated or corrupted backup archive is provided. A panic can occur when a malformed archive produces a non-EOF tar read error after the first entry. Any caller of UploadAllFiles that processes attacker-controlled archive content may be affected. Affected File: [https://github.com/lxc/incus/blob/v6.22.0/…server/storage/s3/transfer_manager.go#L127](https://github.com/lxc/incus/blob/v6.22.0/internal/server/storage/s3/transfer_manager.go#L127) The tar-iteration loop only checks for EOF: Affected Code: ``` for { hdr, err := tr.Next() if err == io.EOF { break // End of archive. } // Skip index.yaml file if hdr.Name == "backup/index.yaml" { ``` When tr.Next() returns a non-EOF error, hdr is nil. The code does not check for this case and immediately dereferences hdr.Name. This was confirmed as follows: Command: ``` go test ./test/fuzz -run='FuzzS3BucketUploadTarParsing/s3_nil_deref_truncated_tar' -count=1 -v ``` Output: ``` === RUN FuzzS3BucketUploadTarParsing === RUN FuzzS3BucketUploadTarParsing/s3_nil_deref_truncated_tar s3_bucket_upload_fuzz_test.go:82: UploadAllFiles panicked: runtime error: invalid memory address or nil pointer dereference --- FAIL: FuzzS3BucketUploadTarParsing/s3_nil_deref_truncated_tar (0.00s) FAIL ``` It is recommended to add a non-EOF error check after tr.Next(). Proposed Fix: ``` hdr, err := tr.Next() if err == io.EOF { break } if err != nil { return fmt.Errorf("Error reading backup archive: %w", err) } ``` A patch is available at https://github.com/lxc/incus/releases/tag/v7.0.0. ### Credits This issue was discovered and reported by the team at 7asecurity (https://7asecurity.com/)