Rule Information
Tags
dockerdockerfiledocker-socketvolumesecurityprivilege-escalationcontainer-escapedaemonhost-accesscritical
CWE References
Interactive Playground
Experiment with the vulnerable code and security rule below. Edit the code to see how the rule detects different vulnerability patterns.
pathfinder scan --ruleset docker/DOCKER-SEC-006 --project .1
2
3
4
5
6
7
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
About This Rule
Understanding the vulnerability and how it is detected
This rule detects VOLUME instructions that mount the Docker socket into a container. Mounting the Docker socket (/var/run/docker.sock or /run/docker.sock) gives a container full control over the host's Docker daemon, which is equivalent to unrestricted root access on the host machine.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Container Escape
Create privileged containers that mount the host filesystem: ```bash docker run -v /:/host --privileged alpine chroot /host /bin/sh ``` This gives the attacker a root shell on the host.
2
Privilege Escalation
Start containers with any user ID, including UID 0 (root), and mount any host directory as a volume.
3
Persistence
Deploy malicious containers that persist across reboots by modifying host systemd services or cron jobs.
4
Data Exfiltration
Access all volumes, images, and containers on the host, including those containing sensitive data from other applications.
5
Resource Hijacking
Deploy cryptocurrency miners or consume all host resources to cause denial of service.
6
Lateral Movement
Access other containers' filesystems and networks, potentially compromising the entire infrastructure. Real-world attack chain: ```bash # Attacker gains shell in container with Docker socket mounted # Step 1: List all containers docker ps -a # Step 2: Create privileged container mounting host root docker run -it -v /:/host --privileged alpine /bin/sh # Step 3: Chroot into host filesystem chroot /host /bin/bash # Step 4: Now has root access to host - install backdoor echo "* * * * * root /tmp/backdoor.sh" >> /etc/crontab ```
How to Fix
Recommended remediation steps
- 1Never mount the Docker socket into application containers
- 2Use the Docker API over TLS with client certificates if remote access is needed
- 3Consider rootless Docker or Podman to reduce socket exposure risk
References
External resources and documentation
Similar Rules
Explore related security rules for Docker
MEDIUM
Sudo Usage in Dockerfile
Dockerfile uses sudo in RUN instructions. This is unnecessary during build (already root) and increases security risk if sudo remains in the final image. Use USER instruction for privilege changes instead.
HIGH
Container Running as Root - Missing USER
Dockerfile does not specify USER instruction. Container will run as root by default, which increases the attack surface if the container is compromised.
CRITICAL
Secret in Build Argument
Build argument name suggests it contains a secret. ARG values are visible in image history via 'docker history'.
Frequently Asked Questions
Common questions about Docker Socket Mounted as Volume
The Docker socket gives unrestricted access to the Docker daemon. A container with the socket mounted can create privileged containers, access host filesystems, and effectively gain root on the host.
Use Docker-in-Docker (dind) with TLS enabled, or use Kaniko/Buildah for building images without requiring Docker socket access.
New feature
Get these findings posted directly on your GitHub pull requests
The Docker Socket Mounted as Volume rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.