CVE-2026-41648: 
NixOS vulnerability analysis and mitigation

CVE-2026-41648 is an unbounded YAML metadata decode vulnerability in Incus (the Linux container and VM manager by Linux Containers) that allows an authenticated attacker to cause a denial of service via memory exhaustion. Affected versions are all releases prior to v7.0.0 (specifically <= 6.23.0 for the Go module github.com/lxc/incus/v6/cmd/incusd). The vulnerability was discovered by the team at 7asecurity, published to the GitHub Advisory Database on May 4, 2026, and assigned CVE-2026-41648 on May 7, 2026. It carries a CVSS v3.1 base score of 5.0 (Medium) and a CVSS v4.0 base score of 5.3 (Medium) (GitHub Advisory, Incus Advisory).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling). The functions getImageMetadata (in cmd/incusd/images.go) and backup.GetInfo (in internal/server/backup/backup_info.go) call yaml.NewDecoder(tr).Decode() directly on a tar reader without first checking hdr.Size or wrapping the reader with io.LimitReader. An attacker can craft a tar archive where metadata.yaml or backup/index.yaml declares a very large size in the tar header; the YAML decoder then reads and allocates proportional memory in the daemon process. The gopkg.in/yaml.v2 library's built-in alias/anchor bomb protection does not prevent large flat YAML documents — memory amplification is linear at approximately 5x–6x the input size, meaning a 200 MB metadata.yaml entry can cause roughly 1.2 GB of heap allocations. Exploitation requires valid API credentials with permission to upload images or backup archives (GitHub Advisory, Incus Advisory).

Successful exploitation causes the Incus daemon process to exhaust available system memory, potentially triggering an out-of-memory condition that renders the entire host server unavailable. Because the decode occurs in the daemon process, excessive garbage-collection pressure can also degrade concurrent container and VM operations even before a full OOM event. There is no confidentiality or integrity impact — the vulnerability is purely an availability (denial of service) issue affecting the Incus server and all workloads it manages (GitHub Advisory).

No confirmed in-the-wild exploitation has been observed, and no weaponized exploit code is publicly available. The GitHub Security Advisory includes vulnerable code snippets and a fuzzing test demonstrating the bug, but no actionable attack steps or crafted payload construction instructions. The EPSS score is approximately 0.043–0.055% (18th percentile), indicating low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires authenticated access with image or backup upload permissions, which limits the attacker pool (Incus Advisory, GitHub Advisory).

1. Obtain authenticated access: Acquire valid Incus API credentials with permissions to upload images or backup archives (e.g., a low-privilege user account on a multi-tenant Incus deployment).
2. Craft a malicious tar archive: Create a tar archive containing a metadata.yaml (for image upload) or backup/index.yaml / backup/container/backup.yaml (for backup restore) entry with a very large declared size in the tar header — for example, a flat YAML document with 50,000+ keys or long string values totaling ~200 MB.
3. Upload the crafted archive: Submit the malicious tarball to the Incus API image import or backup restore endpoint using the Incus client or direct API calls (e.g., incus image import malicious.tar.gz or via the REST API).
4. Trigger memory exhaustion: The Incus daemon's getImageMetadata or backup.GetInfo function calls yaml.NewDecoder(tr).Decode() without size limits, causing the YAML decoder to allocate approximately 5x–6x the input size in heap memory (~1.2 GB for a 200 MB entry), potentially triggering an OOM condition and crashing or severely degrading the daemon (GitHub Advisory, Incus Advisory).

• Logs: Incus daemon logs showing image import or backup restore operations initiated by unexpected or low-privilege users; OOM killer log entries (kernel: Out of memory: Kill process) referencing the incusd process in /var/log/syslog or dmesg.
• Process/Memory: Sudden spike in incusd process memory consumption (RSS growing to several GB) observable via top, htop, or ps aux during or immediately after an image/backup upload operation.
• Network: Large inbound data transfers (hundreds of MB) to the Incus API endpoint from unexpected source IPs, particularly targeting image import or backup restore API paths.
• File System: Presence of unusually large tar archives (>100 MB) in Incus temporary upload directories that contain oversized metadata.yaml or backup/index.yaml entries.

The primary remediation is to upgrade Incus to version 7.0.0 LTS or later, which implements a maxMetadataSize limit (1 MB) and wraps the tar reader with io.LimitReader before YAML decoding (Incus v7.0.0 Release). As interim workarounds, administrators should restrict image and backup upload API permissions to trusted users only, and apply system-level memory limits (e.g., cgroup memory limits or MemoryMax in the incusd systemd unit) to cap the daemon's memory consumption. Monitoring for anomalous memory usage by the incusd process can also provide early warning of exploitation attempts (GitHub Advisory).

The vulnerability was discovered and responsibly disclosed by the security research team at 7asecurity. Incus maintainer Stéphane Graber (stgraber) published the advisory and developed the remediation fix included in v7.0.0. Coverage has been limited to vulnerability database aggregators and Linux security advisory feeds, with no significant broader media or social media discussion observed (Incus Advisory).