WSL2 runs Linux in a lightweight virtual machine on Windows.
Docker Desktop on Windows commonly uses WSL2 integration. This creates a different boundary than native Linux Docker.
The practical lesson is not "WSL2 is Docker escape." The lesson is that the host/container boundary may include Windows, WSL distributions, Docker Desktop, shared filesystems, and exposed management sockets.
What To Identify
From Linux:
uname -a
cat /proc/version
grep -i microsoft /proc/version
mount
ls -la /mnt/c 2>/dev/null
From Windows:
wsl.exe -l -v
docker context ls
docker version
Interesting paths:
/mnt/c
/mnt/wsl
/run/guest-services
/var/run/docker.sock
Common Findings
WSL2/Docker Desktop risks often involve:
- Windows filesystem mounted into Linux
- Secrets available under
/mnt/c/Users/... - Docker socket reachable from a WSL distribution
- Docker Desktop exposing management features
- Developer credentials mounted into containers
- SSH keys, cloud tokens, kubeconfigs, and registry credentials
This is often credential exposure or host file access, not a kernel escape.
Enumeration
Search common developer secrets:
find /mnt/c/Users -maxdepth 5 -type f \( -name ".git-credentials" -o -name "id_rsa" -o -name "config" -o -name "credentials" -o -name "kubeconfig" \) 2>/dev/null
Check Docker access:
ls -la /var/run/docker.sock
docker version
docker context ls
Check Windows mounts:
mount | grep drvfs
ls -la /mnt/c/Users 2>/dev/null
Remediation
- Limit WSL access to sensitive Windows directories.
- Avoid mounting developer home directories into containers broadly.
- Protect SSH keys, cloud credentials, kubeconfigs, and registry tokens.
- Restrict Docker Desktop integration to trusted WSL distributions.
- Keep Docker Desktop and WSL updated.
- Avoid exposing Docker control sockets to untrusted containers or distributions.
- Treat WSL distributions as part of the local security boundary.
WSL2 changes where the boundary sits. Map the boundary before claiming an escape.