CVE-2026-88264: Crun: crun: /dev/console symlink follow allows root-owned file creation outside the rootfs
A flaw was found in crun. During terminal setup, when the OCI configuration does not mount /dev, crun unlinks and recreates /dev/console without preventing symlink follows. A malicious image can make /dev/console a symlink so that crun creates a root-owned file outside the container rootfs. Affected versions are crun 1.29.1 and earlier. This is not CVE-2026-47766, which addressed following a rootfs /dev directory symlink and was fixed in crun 1.28. No fixed release is published yet.
Other sources
A flaw was found in crun. When the container configuration does not give /dev a dedicated mount, terminal setup can redirect /dev/console onto an attacker-controlled path, including via the read-only-rootfs bind-mount fallback. Affected versions are crun 1.29.1 and earlier. Default configurations that mount a fresh /dev are not exposed. No fixed release is available yet.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Ensure OCI/container configuration mounts a dedicated, fresh /dev for the container so that terminal setup does not follow a symlink from /dev/console onto an attacker-controlled path.
- Compensating control
Avoid configurations where /dev is not mounted (so that crun can unlink and recreate /dev/console during terminal setup); configure the runtime/OCI spec to provide /dev dedicated mount semantics instead of relying on the default/unmounted /dev behavior.
Event History
Frequently Asked Questions
Which deployments are exposed?
crun 1.29.1 and earlier are affected when the OCI configuration does not provide a dedicated /dev mount. Default configurations that mount a fresh /dev are not exposed.
What does an attacker need to exploit this?
An attacker needs a malicious container image that makes /dev/console a symlink and a container configuration that does not mount /dev separately. During terminal setup, crun can follow that symlink and create a root-owned file at an attacker-controlled path outside the container rootfs.
Does a read-only root filesystem prevent exploitation?
No. The issue can also be reached through the read-only-rootfs bind-mount fallback when the configuration does not provide a dedicated /dev mount.
What should operators do while no fixed release is available?
Ensure OCI container configurations mount a fresh, dedicated /dev rather than relying on crun's terminal setup to recreate /dev/console. Avoid running untrusted images with configurations that omit this mount.