How to detect and prevent container escapes

Why are container escapes a critical security issue?

Container usage in the cloud continues to grow. About 56% of organizations used containers for production applications, according to the 2025 CNCF survey, up from 41% in 2023. A majority of users deploy containers with Kubernetes and 66% of organizations use it for generative AI workloads.

Given container proliferation, it’s no surprise that threat actors target them. For example, three runc vulnerabilities were disclosed in 2025 that enabled attackers to gain root access to the host system.

Unlike virtual machines (VM), containers share the host’s kernel, which makes them more lightweight and ideal for short-lived workloads, but also susceptible to kernel-level exploits.

One container attack that malicious actors can use is called a container escape. Let’s dig into what a container escape is and explain how you can detect and prevent it.

What is a container escape?

A container escape is when threat actors utilize vulnerabilities, misconfigurations, or privileges to break out of a singular container to gain unauthorized access to the host’s or other containers’ resources.

Containers and VMs isolate workloads from the host server, but while VMs provide hardware-level isolation, containers only offer application-level isolation.

Compromising a container usually only gives attackers access to the resources inside of that single container, but a container escape enables attackers to potentially gain access to your entire server and beyond.

Container escapes work when threat actors use an application vulnerability, stolen credentials, or supply chain attack to gain initial access to a container. From there, they identify excessive privileges, vulnerabilities, or misconfigurations in the container or container runtime to break out.

For example, CVE-2025-31133 is a vulnerability in how runc implements maskedPaths, which can allow attackers to mount arbitrary host paths and write to critical files.

Once threat actors have escaped a container, they can perform attacks that compromise the host, take over clusters, access sensitive data, and move laterally in the server or infrastructure.

6 common container escape techniques

Threat actors have a plethora of options when it comes to container escape attempts. Some common container escape techniques include:

• Excessive capabilities: This involves enabling containers to run elevated Linux capabilities (what actions a process can execute), such as:
  
  • SYS_ADMIN: Allows for filesystem mounting and essentially grants root access to the host.
  • SYS_PTRACE: Allows the use of ptrace() for debugging, but can be used for process injection.
  • SYS_MODULE: Allows a process to unload/load kernel modules, which can be used to bypass security or inject malicious kernel modules.
• Privileged containers: A privileged container has root capabilities and access to host devices. If a container has the --privileged flag, it effectively becomes root on the host. Incorrectly configuring a Kubernetes security context for allowPrivilegeEscalation also lets a process gain more privileges.
• Host filesystem mounts: Attackers can modify host files, escape to the host, and install malware due to improper mounts and docker.sock abuse for full host takeover.
• Kernel vulnerabilities: Attackers exploit Linux kernel vulnerabilities to escape namespace isolation. Examples include Dirty Pipe, Dirty Cow, and the OverlayFS vulnerability.
• Container runtime vulnerabilities: Attackers use vulnerabilities in runc, containerd, or Docker to gain root access, execute malicious code, or escape container isolation.
• Container runtime API abuse: Attackers discover Docker APIs or Kubernetes Kubelet APIs exposed to public-facing internet that lack proper access control or use unencrypted communication.

How to detect a container escape

Traditional security measures, such as static scanning for vulnerabilities and misconfigurations, remain important from a security posture standpoint. However, they struggle with protecting ephemeral workloads because they’re spun up and down constantly.

For container escape detection, you need container runtime security to monitor for suspicious or anomalous behavior in real time and respond promptly. Specific behavior that your container security tools should look for includes unexpected system calls, file access, and processes.

The goal is to detect unexpected behavior, such as a container attempting to disable AppArmor in a production environment instead of using SYS_ADMIN in a development environment.

Getting context around behavior is important, so you can determine whether the behavior is benign or if it signals a container escape attempt. Normal container behavior involves application-focused syscalls.

However, suspicious syscall behavior includes:

• Nsenter: Runs commands within namespaces as another process on the host.
• unshare and setns: Creates a new namespace or joins an existing namespace.
• chmod: Alters access permissions of files.
• mount and umount: Mounts or detaches a filesystem.
• pivot_root: Changes the root filesystem.

Other unexpected behavior involves containers attempting to access sensitive hostPaths, such as /proc or /sys, /var/lib/kubelet, /etc/shadow, or /root. Look for processes attempting capabilities like SYS_ADMIN, SYS_MODULE, or SYS_PTRACE.

Additional behavior to monitor for includes increased compute resource usage, outbound network connections, unexpected package installations, and unexpected spawned shells.

Follow these six steps for performing an investigation into suspicious container activity after receiving an alert:

1. Monitor and identify suspicious processes.
2. Trace the process tree.
3. Check for namespace changes.
4. Inspect container mounts.
5. Analyze any host modifications.
6. Pause or shut down the compromised container.

How to prevent container escapes

Now that you know what behavior to monitor for should a misconfiguration or vulnerability slip past, you need to implement best practices for preventing container escapes.

1. Use strong access control

Limit the existence of root-level permissions to just a few tightly controlled cases. Most users don’t need to run containers with root or privileged mode.

Implement the principle of least privilege (PoLP) to limit your attack surface and reduce privilege escalation attempts by dropping all unnecessary capabilities (--cap-drop all) and adding only relevant capabilities back in.

In Kubernetes, set runAsUser in the Security Context, enable user namespaces, and disable the allowPrivilegeEscalation flag. For Docker, use --security-opt=no-new-privileges and enable User in Dockerfile.

Just implementing and enforcing access control will limit many attack vectors for container escapes.

2. Implement a defense-in-depth security strategy

Strong security often requires multiple tools, tactics, and techniques to keep sensitive data and users protected from malicious actors.

Start by designing a secure container orchestration strategy. Tips include determining how isolated containers should be, using secure container runtimes, and deciding about third-party plugin adoption.

From there, consider implementing:

• Admission controllers: Enhances security by evaluating requests to the Kubernetes API server, enforcing pod security policies, and more.
• AppArmor: Allows for the restriction of capabilities within containers through the use of customizable profiles.
• Seccomp: Enables for the restriction of actions that can be performed inside a container and defined by use of a seccomp profile.
• SELinux: Provides flexible mandatory access control to enforce policies about access to host resources through labeling.
• Network segmentation: Limits lateral movement by breaking the network into smaller segments and then implement granular control over inter-container communication with Network Policies.
• Kubernetes Pod Security Standards: Uses policy levels to define the container policies from privileged to baseline to restricted.

Just seeing a process attempting to disable seccomp or AppArmor is enough of a suspicious signal to warrant further action, such as closely monitoring or isolating the container.

3. Stay atop vulnerability management

Implementing vulnerability management will go a long way to helping prevent many container escapes. You don’t need to address every critical vulnerability that exists. Instead, focus on the ones that could impact your production environments.

For example, regularly patching and updating orchestration tools like runc would prevent CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881. These vulnerabilities enable malicious actors to attack mounts.

But if you use containerd or Docker instead of runc for container runtimes, then these vulnerabilities are something to be aware of but not necessarily fret about. Vulnerability management that includes contextual risk information will help you determine where your energy is best spent.

4. Harden and scan container images

Container image vulnerabilities remain a constant security risk. Ensuring that your images remain updated, secured, and configured correctly is critical.

Container scanning can help to detect known vulnerabilities and misconfigurations before an image is used to create new containers. You should also scan host operating systems to discover vulnerabilities or misconfigurations that would enable container escapes.

Alongside scanning, use software bills of materials (SBOM) to understand every component and dependency used in the container image. This will also help speed up vulnerability management.

Regularly review image configuration to ensure users can’t run as root or privileged. Sign container images with cryptographic hashing to ensure the provenance of the image.

5. Restrict hostPath mounts

Mounting a hostPath volume to containers enables unrestricted access to the host filesystem, which attackers can use to access sensitive files for modification.

Avoid this attack vector by limiting hostPath mounts through the use of PersistentVolumes (PV) or ConfigMaps for regular storage. For sensitive data, like keys, passwords, etc., use Kubernetes Secrets.

Use PodSecurityPolicy to restrict usage of hostPaths with allowedHostPaths: []. Other security suggestions include using Open Policy Agent to block hostPath volumes and enforce PoLP.

6. Use runtime security and monitoring

Static scanning may help to discover known vulnerabilities in containers and images, but monitoring container runtime is critical to detecting potential container escape attempts.

Runtime monitoring includes analyzing kernel telemetry and looking for suspicious or anomalous behaviors. For example, you can use the open source, threat monitoring engine Falco to generate alerts if a container escape is detected, such as attempting to abuse syscalls like the SYS_ADMIN capability.

Immutable cloud workloads shouldn’t experience a change during runtime, so this signals the possibility of container drift. Detect drift with security monitoring tools, such as Falco, to generate an alert if a container executes a new binary.

Implement file integrity monitoring (FIM) to detect when changes to critical files, file systems, databases, and more occur. 

Secure cloud workloads with Sysdig

As you deploy more containers in your production environment, it increases your chances of malicious actors targeting them as an initial access vector into your systems.

It’s important to have deep visibility into container activity to keep sensitive data secure, remain compliant, and reduce your attack surface.

With Sysdig CNAPP, you get a comprehensive cloud security solution to protect all your cloud assets. Sysdig can help you detect and respond to cloud threats quickly without slowing your business down.