T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:133- Finding
Unrestricted Docker Socket Exposure Grants Effective Host Control
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:133
Vulnerability Type: Docker daemon socket exposed to a container
Risk Level: CriticalVulnerable Code:
bash docker run -d --name portainer -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer-data:/data --restart unless-stopped portainer/portainer-ce:latestTechnical Analysis
The deployment command mounts the host Docker daemon socket directly into the Portainer container. Access to
/var/run/docker.sockgenerally provides control over the Docker daemon and is functionally equivalent to root-level host access.A process controlling the socket can create privileged containers, mount arbitrary host directories, access secrets stored in other containers, alter running workloads, and modify host files through bind mounts. The risk is compounded because Portainer is published on all host interfaces and uses a mutable
latestimage tag.Attack Path
- An attacker reaches the Portainer service through TCP port
9000. - The attacker exploits a Portainer vulnerability, compromises an administrator account, or abuses an insecure initial configuration.
- The compromised service communicates with the mounted Docker socket.
- The attacker creates a privileged container or one that bind-mounts the host root filesystem.
- The attacker reads or modifies host files, extracts credentials, accesses other containers, or establishes host-level control.
Impact Assessment
Successful exploitation can provide effective root-level control of the Docker host. The affected scope includes host files, Docker-managed secrets and volumes, all containers controlled by the daemon, attached networks, and data reachable from the host.
- An attacker reaches the Portainer service through TCP port
- Remediation
View remediation
Remediation Suggestions
- Do not mount the raw Docker socket unless it is strictly necessary.
- Prefer a restricted Docker socket proxy that exposes only the minimum API operations required by Portainer.
- Run management interfaces on a dedicated administrative network and bind them to a trusted address rather than all interfaces.
- Require strong authentication, protect initial setup, and place the interface behind TLS and network allowlisting.
- Pin the Portainer image to a reviewed version and immutable digest.
- Apply defense-in-depth controls such as a read-only root filesystem, dropped Linux capabilities,
no-new-privileges, and host firewall rules. - Monitor Docker daemon API activity for unexpected privileged-container creation and host bind mounts.
