GHSA-fwj8-62r8-8p8m
MEDIUMGHSA-fwj8-62r8-8p8m is a medium-severity (CVSS 6.5) NULL Pointer Dereference vulnerability in github.com/lxc/incus/v6/cmd/incusd. O3 Security confirms whether GHSA-fwj8-62r8-8p8m is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Incus has Nil-Pointer Dereference via S3 Bucket Import
Blast Radius
github.com/lxc/incus/v6/cmd/incusdReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
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
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/)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/lxc/incus/v6/cmd/incusd | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/lxc/incus/v6/cmd/incusd. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of github.com/lxc/incus/v6/cmd/incusd has shipped for GHSA-fwj8-62r8-8p8m yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-fwj8-62r8-8p8m is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-fwj8-62r8-8p8m. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-fwj8-62r8-8p8m in your dependencies?
O3 detects GHSA-fwj8-62r8-8p8m across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.