Imagine you have an app that you want to run on your computer. This app needs certain things to work, like specific versions of software or libraries. Usually, setting all this up can be tricky because your computer might not have the exact versions needed, or other apps might need different versions of the same software.

A container is like a small, portable box that has everything your app needs to run. This box includes:

• Your app
• All the software and libraries your app depends on
• Configuration files and settings

An added benefit to containers is that they are isolated from the surrounding host system. This is very important for security when deploying containers for an end user as a service, because it prevents unauthorized access to sensitive data. If this isolation were to be breached, a user of the system could access information that should not be accessible to them, and abuse privileges that they should not have.

This type of exploit is known as a container escape. With the rise of microservices and containerization over the last decade, more and more systems are becoming potentially vulnerable to this type of attack. The implications vary from system to system, but it is common for user data and system details to be vulnerable in the event of a container escape.

Container escapes can happen as a result of a few different common vulnerabilities. The most common is a simple misconfiguration of the container, giving that container too many privileges which can be exploited by a malicious user. Other common vulnerabilities include kernel-based vulnerabilities, improper usage of namespaces, and vulnerable or malicious container images.