When executing the default image, the response is a conditional number. The capabilities of the kernel are limited, the file system is limited, the process space is isolated, and it is located on a separate bridge network from the host. Anything that allows access to the host will be a security vulnerability.
The conditional part is that it can use all your processor cycles, it can run out of memory, it can fill up your disk, and it can send network traffic from your NAT'ed device to your IP address. In other words, by default, nothing prevents the container from attacking DoS on your host.
Docker has the ability to limit many of these things, including limiting memory, limiting processor or prioritization processes, and quota file system solutions.
You can also go in another direction and open the node to the container, effectively creating security vulnerabilities. This will include mounting hosts, especially docker.sock inside the container, removing kernel restrictions with --privileged and removing network isolation with --net=host . Running any of these using the container disables the default protection provided by Docker.
Docker has a lower isolation level than a virtual machine due to the way it shares the kernel with the host. Therefore, if the code you use contains a kernel or a physical hardware exploit that can access the host. For this reason, if you use untrusted code, you may need to study linuxkit, which provides a lightweight container-based operating system for working inside vm. This is used to provide os mobility, which runs under hyperv / xhyve on the docker for windows / mac.