This page lists security vulnerabilities which Docker mitigated, such that
processes run in Docker containers were never vulnerable to the bug—even before
it was fixed. This assumes containers are run without adding extra capabilities
or not run as
The list below is not even remotely complete. Rather, it is a sample of the few bugs we’ve actually noticed to have attracted security review and publicly disclosed vulnerabilities. In all likelihood, the bugs that haven’t been reported far outnumber those that have. Luckily, since Docker’s approach to secure by default through apparmor, seccomp, and dropping capabilities, it likely mitigates unknown bugs just as well as it does known ones.
mount(). All of these CVEs are examples of security vulnerabilities due to introduction of user namespaces. Docker can use user namespaces to set up containers, but then disallows the process inside the container from creating its own nested namespaces through the default seccomp profile, rendering these vulnerabilities unexploitable.
NO_NEW_PRIVSprocess flag and other mechanisms.
ptrace()could allow privilege escalation. Docker disables
ptrace()inside the container using apparmor, seccomp and by dropping
CAP_PTRACE. Three times the layers of protection there!
keyctl()calls could cause kernel DoS / memory corruption. Docker disables
keyctl()inside containers using seccomp.
--privileged. Interestingly, these seem to be cases where containers are “more secure” than a VM, going against common wisdom that VMs are “more secure” than containers.
keyctl()calls could lead to privilege escalation. Docker disables
keyctl()inside containers using the default seccomp profile.
bpf()system call is blocked inside Docker containers using (ironically) seccomp.
ARPT_SO_SET_REPLACEcausing memory corruption / local privilege escalation. These arguments are blocked by
CAP_NET_ADMIN, which Docker does not allow by default.
Bugs not mitigated:
modify_ldt()system call is not currently blocked using seccomp.
ptraceand the fact that