A read-only container filesystem can still leave the host exposed before the container is fully established. CVE-2026-88264 is a useful reminder that container security is partly about *when* the runtime resolves paths, not just what permissions exist after startup. In the vulnerable crun path, `/dev/console` could be interpreted before `pivot_root`, while the runtime could still resolve against the host's mounted filesystems. That creates an awkward governance problem: a control can be correctly configured for the running workload and still be irrelevant to a failure that occurs during setup. **In practical terms, it is a good time to:** - identify hosts and nodes using crun and record the packaged runtime version - inspect custom OCI specs for configurations that omit a separate `/dev` mount - compare generated specs from internal tooling with Docker, Podman, containerd, or CRI-O defaults - review image admission rules for untrusted or unsigned images - test whether runtime setup rejects a symlinked `/dev/console` path Where else are we relying on a control that only becomes effective *after* the risky operation has already happened? Read the full analysis: #LinuxSecurity #ContainerSecurity #DevSecOps #InfrastructureSecurity #OpenSource https://linuxsecurity.com/features/malicious-container-image-crun-linux-host