CVE-2026-48750 in Incus is a symlink traversal that lets an attacker with instance access write arbitrary content to host paths. The mechanism is straightforward: the /instances/$name/exec endpoint accepts an exec-output parameter specifying where to write stdout, and an attacker can create a symlink named exec-output pointing to any writable host directory before calling exec. The arbitrary .stdout file then lands where the attacker chose.
What makes this worth your attention isn't the exploit mechanics—it's what the vulnerability reveals about trust assumptions in container management APIs. The developers correctly validated that exec-output resolves to a directory within the instance namespace. What they missed is that symlink resolution operates below the namespace boundary at the filesystem layer, which the application never models. The security boundary (the instance namespace) and the attack surface (a user-controlled path parameter) operate on different definitions of 'inside.'
This is not an Incus-specific failure. The same genotype—symlink traversal exploiting implicit trust at namespace boundaries—has appeared in Docker (CVE-2018-15664), LXC, runc, and Kubernetes container runtime interfaces. The pattern recurs because container APIs treat instance-internal paths as user-controlled configuration while simultaneously relying on those paths as containment boundaries. Neither side fully owns the validation because each assumes the other handles it.
For defenders, the actionable implications are concrete. First, audit your container/VM management APIs for any user-controlled path parameters that write to locations within a managed namespace—these are the structural equivalent of this bug waiting to surface. Second, implement explicit symlink resolution validation (filepath.EvalSymlinks or equivalent) on any path parameter that crosses a security boundary, regardless of whether the path is already validated as 'inside' a container. Third, treat namespace boundaries as necessary but insufficient—assume they do not constitute filesystem boundaries unless explicitly validated.
The deeper question is whether your codebase has accumulated the same sediment: implicit trust in path parameters that was added during initial development and never challenged as the API grew. That's where the next vulnerability lives.