Vulhub: Pre-Built Vulnerable Docker Environments for Security Research

What Vulhub Provides and Who Uses It

Vulhub is a collection of pre-built, ready-to-use vulnerable Docker environments. Each environment reproduces a specific vulnerability in a real software product, and the README states that with one command you can launch a vulnerable environment for security research, learning, or demonstration, with no prior Docker experience required.

The target users are security researchers who need to study a vulnerability's behavior, students preparing for penetration testing certifications or CTF competitions who want hands-on practice, and security teams that want to demonstrate a vulnerability to stakeholders without setting up a full lab. A developer who wants to understand how an old version of Elasticsearch, Weblogic, or Tomcat behaves under a specific exploit can clone the repository, navigate to the relevant directory, and have a running environment in minutes.

Vulhub is not a CTF platform. There are no challenges, no scoreboards, and no hints. It is a reference library of environments, each with a README documenting the vulnerability and reproduction steps. The distinction from platforms like VulnHub (which provides downloadable virtual machine images for CTF-style challenges) is that Vulhub provides Docker-based environments focused on specific real-world CVEs rather than puzzle-style challenges.

Repository Layout: Software Products and CVE Directories

The repository organizes environments by software product at the top level. The top-level directory listing in the repository includes directories for activemq, adminer, airflow, apache-cxf, apache-druid, apereo-cas, apisix, appweb, aria2, bash, budibase, cacti, celery, cgi, confluence, couchdb, craftcms, cups-browsed, dataease, discuz, django, drupal, dubbo, elasticsearch, electron, elfinder, fastjson, ffmpeg, flask, flink, geoserver, ghostscript, git, gitea, gitlab, gitlist, glassfish, and many more. Each product directory contains one or more subdirectories named by CVE identifier or a descriptive vulnerability name.

The example in the README uses vulhub/langflow/CVE-2025-3248 to illustrate the pattern. Within each CVE directory, a README documents the vulnerability details, the affected version, and the steps to reproduce the exploit against the running environment.

This flat per-product-per-CVE structure means finding a specific environment requires knowing either the product name or the CVE number. The repository also provides an environments.toml file at the root, which appears to be a machine-readable index of available environments, though the provided file listing does not include its contents. The project website at vulhub.org/environments lists the catalog in a browsable format.

Starting and Cleaning Up a Vulnerable Environment

Setting up Docker on Ubuntu 24.04 follows the steps the README provides:

curl -s https://get.docker.com/ | sh
systemctl start docker

For other operating systems, the README points to the Docker documentation. The built-in docker compose command (the modern form, not the legacy docker-compose binary) is the only prerequisite beyond Docker itself.

Downloading Vulhub:

git clone --depth 1 https://github.com/vulhub/vulhub

The --depth 1 flag fetches only the latest commit rather than the full history, which keeps the initial download small given the size of the repository. Launching a specific vulnerable environment requires navigating to its directory and running docker compose:

cd vulhub/langflow/CVE-2025-3248
docker compose up -d

The -d flag runs the containers in the background. Each environment directory contains a docker-compose.yml and a README with reproduction steps. After finishing a test, cleaning up removes the containers and volumes:

docker compose down -v

The -v flag removes the named volumes created by the environment, which prevents leftover data from affecting a subsequent run.

Platform Constraints and Troubleshooting

The README documents three specific failure modes that users encounter regularly. First, Docker Hub may be inaccessible from mainland China; the workaround is to use a registry mirror or run Vulhub on an overseas VPS.

Second, M-series Mac hardware (Apple Silicon) requires an explicit platform setting for environments whose images were not built for ARM:

export DOCKER_DEFAULT_PLATFORM=linux/amd64
docker compose up -d

The README states that most Vulhub environments run natively on Docker Desktop for Mac with M-series chips, but some require this override. The amd64 emulation works but runs slower than native execution.

Third, Kali Linux users may encounter failures caused by a low ulimit nofile setting. The README directs them to the FAQ at vulhub.org/documentation/faq for the fix rather than documenting it inline. This is a platform-specific operating system configuration issue rather than a Vulhub bug.

The README also notes that the `your-ip` placeholder in environment documentation refers to the host or VPS IP address, not the Docker container's internal IP. This is a common source of confusion when following reproduction steps, particularly for environments that expose services on non-standard ports.

Vulhub Compared to Downloading Vulnerable Virtual Machines

The traditional approach to vulnerability research labs involves downloading a virtual machine image with a vulnerable application pre-installed, or manually installing an old software version in a VM. This works but has drawbacks: VM images are large (often several gigabytes), the images are static snapshots that do not receive any maintenance, and removing or resetting the environment requires deleting and re-importing the VM.

Vulhub's Docker approach is more granular. Each environment contains only the components needed to reproduce the specific vulnerability, built from a docker-compose.yml that pulls the relevant images on demand. Cleanup with docker compose down -v removes everything. Running multiple environments simultaneously is straightforward because each runs in its own network namespace.

The trade-off is that Vulhub environments are not full operating systems. They reproduce the vulnerable service, not an entire attack surface. A researcher who needs to practice privilege escalation or lateral movement after exploiting the initial vulnerability will need to add additional infrastructure beyond what Vulhub provides. For learning about a specific CVE in isolation, Vulhub's scope is sufficient.

Scope, Coverage, and What Is Not Included

The repository covers a broad range of server-side software: application servers, CMSes, databases, message queues, workflow engines, and developer tools. The top-level directory listing alone shows over 40 product categories, and the environments.toml at the repository root provides a structured index of all available environments.

The README does not state the total number of environments. The project website at vulhub.org/environments is described as providing the count. The directory structure shows some products have many CVE subdirectories (GitLab, Confluence, Elasticsearch) while others have one or two.

Client-side vulnerabilities (browser exploits, PDF reader vulnerabilities, Microsoft Office macros) are not represented in the visible structure. The collection focuses on server-side software that runs in Docker containers. Vulnerabilities in operating system kernels or hardware are also outside the scope, since Docker environments share the host kernel.

The last push to the master branch was on 2026-09-18. The repository is not archived. New environments are contributed by the community; the CONTRIBUTING.md documents the process for adding a new environment.

License and Safe Use

Vulhub is licensed under the MIT License. This permits use for any purpose, including commercial security testing labs and training programs, without requiring source release of derivative works. The README carries an explicit warning: all environments are for testing and educational purposes only and must not be used in production.

Running a Vulhub environment exposes a deliberately vulnerable service on the host's network. The README's recommendation to use a VPS or VM rather than a local machine reflects the risk: a vulnerable environment on a developer's workstation connected to a shared network is accessible to others on that network. The docker compose down -v cleanup step is not optional in shared environments; leaving a vulnerable container running is a security risk to the host network.

The project accepts sponsorship through GitHub Sponsors, OpenCollective, and Patreon, as noted in the README. The listed partners include wangan.com, cvebase.com, huoxian.cn, chaitin.cn, and Alibaba Cloud's xianzhi.aliyun.com.

Editorial conclusion

Vulhub is a practical tool for security researchers and students who need a reproducible, disposable vulnerable environment to study a specific CVE or software weakness. The single-command startup removes the overhead of manually configuring a vulnerable application version. It is not a CTF platform and does not provide challenge scoring or hints; it is a library of environments. Before using Vulhub in a team context, read the README's note about using a VPS or VM with at least 1 GB of RAM, confirm Docker has permission to access the working directory, and check whether the target environment's README mentions ARM incompatibility, since not all images support M-series Mac hardware.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. vulhub/vulhub on GitHub