CVE-2026-48750 in Incus
Summary
by MITRE • 08/21/2026
Incus is a system container and virtual machine manager. Prior to version 7.2.0, the `record-output` parameter of the `/instances/$name/exec` endpoint stores the output of the command in the `exec-output` directory of the instance. If `exec-output` is a symlink, file named `exec_UUID.stdout` and `exec_UUID.stderr` can be written to an arbitrary location where the `.stdout` file will contain arbitrary content. This behavior can be abused for arbitrary command execution. Version 7.2.0 contains a patch.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/21/2026
Incus is a system container and virtual machine manager that provides infrastructure orchestration capabilities similar to Docker but focused on full systems rather than just applications. The vulnerability identified in versions prior to 7.2.0 resides within the execution endpoint for instances, specifically affecting how command output is handled during remote or local process executions. When an administrator or authorized user invokes a command via the /instances/$name/exec API endpoint with the record-output parameter enabled, Incus attempts to persist the standard output and standard error streams of that command into files located in the exec-output directory associated with the target instance. This design choice assumes that the exec-output directory is a secure, controlled location within the container's filesystem namespace.
The core technical flaw stems from an insufficient validation mechanism regarding symbolic links during file creation operations. If an attacker or malicious actor has write access to the instance and can manipulate its filesystem structure, they may replace the legitimate exec-output directory with a symbolic link pointing to an arbitrary path on the host system or another accessible location within the container's namespace where they possess write permissions. When Incus proceeds to create the temporary files named exec_UUID.stdout and exec_UUID.stderr for storing command results, it fails to verify that the target of the symlink is still the intended directory. Consequently, these output files are written directly into the arbitrary destination specified by the symlink.
This behavior leads to a critical security impact because many system services and container runtimes monitor specific log or temporary directories for new content as part of their operational logic. By writing controlled data into an arbitrary location via the stdout file, an attacker can potentially trigger unintended behaviors in other processes that read from those locations. For instance, if the symlink points to a directory monitored by a service like systemd-journald, rsyslog, or even application-specific log parsers, the injected content might be interpreted as valid configuration data, script input, or command arguments depending on the context of the consuming process. This mechanism effectively allows for arbitrary code execution through file injection and subsequent exploitation of downstream services that trust their input sources without adequate sanitization.
From a classification perspective, this vulnerability aligns with CWE-59 Improper Link Resolution Before File Access, commonly known as a symbolic link following or symlink race condition variant where the check is not atomic or properly validated against directory traversal attacks. In terms of offensive security frameworks such as MITRE ATT&CK, this technique relates to T1036 Masquerading and potentially T1548 Abuse Elevation Control Mechanism if it leads to privilege escalation within the container environment. The attack vector requires local access to the instance or API with sufficient privileges to create symlinks and invoke exec commands, placing it in the Local category rather than remote network exploitation.
To mitigate this vulnerability, organizations running Incus must upgrade immediately to version 7.2.0 or later, where the patch ensures that output files are written securely without following maliciously crafted symbolic links. In environments where upgrading is not immediately feasible, administrators should enforce strict filesystem permissions on instance directories to prevent unauthorized users from creating symlinks within critical paths like exec-output. Additionally, implementing file integrity monitoring tools can help detect unexpected changes in directory structures or the creation of symbolic links pointing outside expected boundaries. Regular audits of container configurations and adherence to least-privilege principles for API access further reduce the risk surface associated with such filesystem manipulation attacks.