---
title: "A House of Cards: An Exploration of Security When Building Docker Containers"
description: "The post examines how a Docker-based, multi-tenant build environment can expose untrusted code when layered isolation is misconfigured. It traces a setup using AWS CodeBuild, Docker-in-Docker, and per-step build containers, then tests directory traversal through configurable Dockerfile paths before focusing on daemon networking. The vulnerability comes from starting dockerd with tcp://0.0.0.0:2375 and placing containers on a shared default network; build code can reach the daemon, issue Docker commands, mount the host filesystem, and retrieve container-managed AWS credentials. The excerpt reports a reverse shell, access to the CodeBuild filesystem, and temporary credentials whose impact depends on IAM permissions, while noting that the build must remain alive. The stated fix is to remove the TCP listener and retain the mapped Unix socket."
---

# A House of Cards: An Exploration of Security When Building Docker Containers

[Heroku](https://yomu.fyi/company/heroku) · Etienne Stalmans · Mar 8, 2018

**Type:** Incident / postmortem

## Summary

The post examines how a Docker-based, multi-tenant build environment can expose untrusted code when layered isolation is misconfigured. It traces a setup using AWS CodeBuild, Docker-in-Docker, and per-step build containers, then tests directory traversal through configurable Dockerfile paths before focusing on daemon networking. The vulnerability comes from starting dockerd with tcp://0.0.0.0:2375 and placing containers on a shared default network; build code can reach the daemon, issue Docker commands, mount the host filesystem, and retrieve container-managed AWS credentials. The excerpt reports a reverse shell, access to the CodeBuild filesystem, and temporary credentials whose impact depends on IAM permissions, while noting that the build must remain alive. The stated fix is to remove the TCP listener and retain the mapped Unix socket.

## Context

A multi-tenant build environment executes untrusted user-supplied code through AWS CodeBuild, Docker-in-Docker, and Docker build containers. The post investigates how a small Docker daemon networking misconfiguration could defeat the intended isolation between those layers.

## Approach / What changed

The investigation tests configurable Dockerfile paths for directory traversal, examines Docker-in-Docker daemon behavior, and demonstrates access from a temporary build container to the daemon, the underlying CodeBuild filesystem, and container-managed AWS credentials. The proposed patch removes the dockerd TCP listener on 0.0.0.0:2375 while retaining the mapped Unix socket.

## Takeaways

- Binding dockerd to tcp://0.0.0.0:2375 exposed the daemon to build containers sharing the default Docker network.
- Access to the Docker daemon enabled mounting the host filesystem and reaching the underlying AWS CodeBuild environment.
- Removing the TCP listener fixes the described issue because the mapped Unix socket is sufficient for Docker-in-Docker.

**Tags:** [AWS](https://yomu.fyi/topic/aws), [Docker](https://yomu.fyi/topic/docker), [Security](https://yomu.fyi/topic/security)

- Source: [Heroku](https://www.heroku.com/blog/exploration-of-security-when-building-docker-containers)
- Source URL: https://www.heroku.com/blog/exploration-of-security-when-building-docker-containers
- Ingested by Yomu: 2026-09-09T14:26:02.095Z

[Read original post](https://www.heroku.com/blog/exploration-of-security-when-building-docker-containers)