Back to Articles

Vulhub: How Docker Compose Became the Swiss Army Knife of Vulnerability Research

[ View on GitHub ]

Vulhub: How Docker Compose Became the Swiss Army Knife of Vulnerability Research

Hook

What if spinning up a vulnerable environment for security research took just two commands? That’s the promise Vulhub delivers with its collection of pre-built Docker environments.

Context

Security researchers and penetration testers face a perpetual problem: reproducing vulnerabilities requires recreating the exact environment where they exist. Setting up the right software versions, configuring dependencies, and matching vulnerable system states traditionally required deep DevOps experience and significant time investment.

Vulhub emerged from this friction. Rather than treating each CVE as requiring custom configuration, the project applies infrastructure-as-code principles to vulnerability reproduction. Each vulnerability becomes a declarative Docker Compose file that encapsulates the vulnerable stack—application code, runtime, dependencies, and misconfigurations. The result is a living library of vulnerable environments spanning web frameworks, databases, enterprise software, and other systems. Clone the repo, navigate to a vulnerability directory, run docker compose up, and you have a working vulnerable environment.

Technical Insight

Vulnerability Environment

Selects CVE

Navigate to

Orchestrates services

Defines vulnerable state

Guides exploitation

Spins up

Test/exploit

docker compose down -v

Destroys completely

Security Researcher

Vulhub Monorepo

Vulnerability Directory

docker-compose.yml

Dockerfiles

README Documentation

Docker Engine

Isolated Vulnerable Container

System architecture — auto-generated

Vulhub’s architecture is built around Docker Compose orchestration: a monorepo where each vulnerability lives in its own directory with a docker-compose.yml file and application-specific configuration. The genius lies in the isolation model and standardization.

Each environment directory contains a docker-compose.yml that defines the minimal service topology needed to expose the vulnerability, along with a detailed README documenting reproduction steps and usage instructions. Dockerfiles pin exact versions to ensure reproducibility—the project appears to maintain snapshots of software at their vulnerable states, pulling from archives or specific commits that contained security flaws.

The standardized workflow follows a consistent pattern across all environments:

# Navigate to vulnerability directory
cd vulhub/langflow/CVE-2025-3248

# Start environment
docker compose up -d

# Test/exploit according to README

# Clean up completely
docker compose down -v

The -v flag in the teardown command is critical—it removes volumes, ensuring no state persists between tests. This statelessness means researchers can rapidly iterate: test an exploit, tear down, modify approach, and rebuild quickly.

What separates Vulhub from simple Docker images is the educational scaffolding. Each environment’s README documents the vulnerability mechanics and provides reproduction steps, transforming the project from a mere testing tool into a learning platform.

The project leverages Docker’s built-in networking and isolation capabilities, with the README noting that users no longer need to install docker-compose separately—they can use the built-in docker compose command instead.

Gotcha

Vulhub’s Docker-centricity creates real friction on Apple Silicon Macs. The README explicitly warns that some environments may not support ARM architectures. While most environments appear to run on Docker Desktop for Mac with M-series chips, failures can occur. The suggested workaround is setting the platform explicitly: export DOCKER_DEFAULT_PLATFORM=linux/amd64 before running docker compose up. However, this doesn’t solve all compatibility issues and may impact performance.

Geographic accessibility is another genuine barrier. The README acknowledges that Docker Hub may be inaccessible from mainland China, making image pulls fail or timeout. The suggested workarounds—using registry mirrors or running on overseas VPS instances—add friction that undermines the simplified setup philosophy.

The README also warns about issues on Kali Linux due to low ulimit nofile settings, requiring manual configuration adjustments.

Most critically, these are intentionally vulnerable environments. The README explicitly states: ‘All environments are for testing and educational purposes only. Do not use in production!’ The documentation notes that ‘your-ip’ refers to your host/VPS IP, not the Docker container IP, suggesting network exposure concerns. Run Vulhub only on isolated networks or properly firewalled systems—the ease of docker compose up makes accidental exposure to the internet a real risk.

Verdict

Use Vulhub if you’re learning offensive security techniques, need to reproduce a specific CVE for research, or teaching penetration testing and want students focused on exploitation rather than environment setup. It appears well-suited for security teams validating whether their defenses detect known attack patterns, or developers wanting to understand exactly how a vulnerability works. The instant-on nature makes it suitable for workshop environments where setup time matters. Skip it if you need production-grade testing environments—these are intentionally vulnerable by design. Avoid it for air-gapped research labs without Docker Hub access, or if your team exclusively uses ARM-based development machines without tolerance for potential compatibility issues. The project recommends using a VPS or VM with at least 1GB RAM for best results, and emphasizes that these environments are strictly for testing and educational purposes.

// ADD TO YOUR README
[![Featured on Starlog](https://starlog.is/api/badge/cybersecurity/vulhub-vulhub.svg)](https://starlog.is/api/badge-click/cybersecurity/vulhub-vulhub)