vulhub for spinning up intentionally vulnerable docker labs in one command

vulhub packages hundreds of pre-built, deliberately vulnerable applications as docker compose stacks so authorized testers and students can study real CVEs in isolated labs with a single command.

Tool	vulhub/vulhub — open-source collection of pre-built vulnerable Docker environments for security research and training
Category	Vulnerable environment / security training lab framework
Primary Use	Launching reproducible, CVE-specific vulnerable services locally via docker compose up -d for learning, demonstrations, and exploit research
Safe Use	Strictly for authorized training, labs, CTF practice, and defensive research; the README explicitly warns all environments are for testing and educational purposes only and must never be used in production
Telemetry Note	Leaves obvious local traces: Docker images and containers on the host, docker compose logs, and services listening on lab ports — trivially observable and expected only on isolated research machines

vulhub is one of the most widely adopted open-source projects in the security training space, and its repository metadata makes that plain: north of twenty-one thousand stars, a primary language of Dockerfile, an MIT license, and topics that read like a mission statement — docker, docker-compose, dockerfile, and vulnerability-environment. The premise is deceptively simple. Instead of hand-installing an old, buggy version of a web framework every time you want to study a specific CVE, vulhub gives you a directory per vulnerability containing a ready-made docker-compose.yml and the supporting files needed to bring the flawed software up in seconds. It is, in effect, a distributed museum of exploitable software that runs on demand and tears down cleanly.

The workflow the README describes requires essentially no prior Docker experience. You install Docker on a Linux host — the README shows the convenience script from get.docker.com piped to sh as one example for Ubuntu 24.04 — then clone the repository with git clone --depth 1, cd into the directory for the vulnerability you care about, and run docker compose up -d. Cleanup is symmetric: docker compose down -v removes the containers and their volumes. Notably, the project no longer asks users to install the standalone docker-compose binary; the built-in docker compose subcommand is sufficient, which removes one of the classic friction points that used to trip up newcomers to this kind of lab tooling.

Structurally, the repository is organized as a tree of environment directories, each named for the target software and the specific identifier of the flaw — the README's worked example is vulhub/langflow/CVE-2025-3248. That naming convention is the real interface of the project: browsing vulhub.org/environments or the repo tree gives you an index of vulnerabilities, and each leaf directory is a self-contained lab. The project tracks a large and growing count of environments — the README's badge pulls the number dynamically from vulhub.org/api/statistic — and the inclusion of a 2025 CVE as the flagship example signals that the collection is actively maintained rather than a frozen archive of legacy bugs.

A detail that matters for anyone building a study plan around this: every environment directory ships with its own detailed README containing reproduction steps and usage instructions. This is where the pedagogical value concentrates. The top-level documentation gets you the container running; the per-environment documentation tells you what the vulnerability class is, what component is affected, and how the flaw manifests, which is what turns a running container into a learning exercise rather than an opaque service. For trainers building curricula, this means each directory can be assigned directly as lab material without writing supplementary setup docs.

Operationally, the README's notes section is worth reading carefully because it encodes the hard-won lessons of thousands of users. The recommended host is a VPS or VM with at least 1GB of RAM. The documentation's your-ip placeholder refers to the host or VPS address, not the container's internal IP — a distinction that regularly confuses beginners attacking the wrong interface. Docker must have permission to access files in the working directory to avoid permission errors, and some environments do not support ARM architectures, which is cross-referenced to the troubleshooting section.

That troubleshooting section is unusually honest about the real-world failure modes. Users in mainland China may find Docker Hub unreachable and need a registry mirror or an overseas VPS. On Apple Silicon Macs, most environments now run natively under Docker Desktop, but failures can be worked around by exporting DOCKER_DEFAULT_PLATFORM=linux/amd64 to force amd64 emulation before docker compose up -d. On Kali Linux, some stacks fail due to a low ulimit nofile setting, with the fix documented in the project FAQ at vulhub.org. The project also runs a Discord community and maintains a presence on X, which is the sanctioned channel for help when local debugging stalls.

From a defensive-research standpoint, vulhub occupies a distinctive niche in the ecosystem. It is not a scanner, not a framework, and not an exploitation tool — it is infrastructure for reproducibility. When a new CVE drops, having a vulhub environment for it lets defenders stand up the exact affected software, watch how their detection stack behaves against the relevant techniques, and validate that a patch or mitigation actually neutralizes the flaw, all without hunting for a legacy installer or a vulnerable version of a dependency. That same property makes it a natural companion to signature development and purple-team exercises conducted inside an authorized lab.

For penetration testers preparing for engagements, the legitimate role is skill maintenance and proof-of-concept comprehension: understanding a vulnerability class deeply enough to recognize it in a client's environment, on systems you are contractually authorized to assess. The environments are deliberately fragile, often exposing administrative interfaces, default credentials, and known-vulnerable library versions, which is precisely why the README's warning is set in bold: all environments are for testing and educational purposes only, do not use in production. Deploying one of these stacks on an internet-facing host is functionally publishing a compromise-me sign, so isolation — a VM, a lab network segment, a firewalled VPS — is not optional hygiene but the core operating requirement.

The project's governance round out the picture. It is MIT licensed, accepts contributions through a documented CONTRIBUTING.md guide, displays an anonymous contributors list, and is funded through GitHub Sponsors, OpenCollective, and Patreon, with visible partnerships from Chinese security firms and platforms including Chaitin, Huoxian, Aliyun Xianzhi, CVEBase, and Wangan. This commercial-adjacent backing is a good sign for longevity: environments track current CVEs, the documentation site is maintained, and there is an organizational incentive to keep the collection fresh. The availability of a Chinese-language README (README.zh-cn.md) also reflects the project's origins and its substantial bilingual user base.

The footprint vulhub leaves on a host is worth stating explicitly for anyone running labs on shared or semi-shared infrastructure. After a session you will have pulled Docker images of the vulnerable software, created named containers and volumes, and left services bound to ports on the host — all visible through docker ps, docker images, and docker volume ls. Because the bundled software is intentionally flawed, a forgotten docker compose up -d is a standing risk; the correct habit is to treat docker compose down -v as the mandatory last step of every exercise. On the blue-team side, that same observability means a vulhub stack running where it should not be is easy to detect and should be treated as a high-priority finding in its own right.

In sum, vulhub is arguably the lowest-friction entry point into hands-on vulnerability study available today. One git clone, one docker compose up -d, and you are looking at a faithful reproduction of a real CVE's conditions, with per-directory documentation to guide the analysis and a clean teardown path. For authorized professionals — students, trainers, detection engineers, and pentists maintaining currency — it converts what used to be hours of environment wrangling into minutes, and its sustained maintenance and community support make it a reasonable foundation for a long-term lab practice.

Official project repository for vulhub/vulhub.

Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.