oO This one is a clear vulnerability -- if you're able to escape a container and access the host system (usually with root access since Docker is running as root most places), that's a big issue.
I even resorted to posting instructions on stack exchange demonstrating how to walk /sys to find device numbers and use mknod to read the hosts root volume and now as most servers don't mount their efi partition, how you could mount it rw inside a container with little effort.
Containers are namespaces and purely depend on privilege dropping for the security they provide.
Part of the problem is that container breakout is narrowly defined.
The fact that a privileged container can upload firmware or access private keys by reading the hosts root volume didn't count.
While the ability to disable privileged mode wouldn't have solved this issue it still would have reduced the attack surface. But will the projects refusal to even take that step I gave up.
Deciding that the only safe option was to consider containers as namespaces and nothing more.
Unfortunately adding persistence and other functionality tends to result people running it as uid0, which means that you have to consider as anything that can launch a container as having superuser privileges.