WebSploit Labs gives a security class its own network of broken apps

A classroom network, not a scanner

The repository is a learning environment rather than a piece of tooling, and the README is explicit about the intent. WebSploit Labs is a learning environment created by Omar Santos for different Cybersecurity Ethical Hacking, Bug Hunting, Incident Response, Digital Forensics and Threat Hunting training sessions. It has been used by many colleges and universities in different countries, and it comes with over 500 distinct exercises. What ships in the box is several intentionally vulnerable applications running in Docker containers on top of Kali Linux or Parrot Security OS, several additional tools, and over 9,000 cybersecurity resources. The scale of that last figure is the part that surprises people, since the containers are the memorable half and the resource library is the bulk of the repository. The audience is an instructor, or a student in a course where the instructor has pointed everyone at it, and the project is GPL-3.0 with the site at websploit.org. The repository is not archived and the last push was on 2026-10-13, so the lab set keeps growing as new exercises are added.

A fixed address plan, because the exercises refer to IPs

The architectural decision that makes the lab work is that every container gets a hardcoded address on one network, the WebSploit Network at 10.6.6.0/24, and the exercises can therefore refer to a specific IP. The compose file pins each service with an ipv4_address, and the README reproduces the same plan as a diagram. Three well known applications sit at the bottom of the range, webgoat at 10.6.6.11 for comprehensive web security training, juice-shop at 10.6.6.12 as a modern vulnerable web app with CTF challenges, and dvwa at 10.6.6.13 as the classic security training target. Then the custom labs start at 10.6.6.20, with three themed challenges in the twenties, galactic-archives as a sci-fi themed CTF, gravemind with a Halo theme and y-wing with a Star Wars theme. Everything from 10.6.6.30 upwards is a single vulnerability class per container, and the naming makes the syllabus readable at a glance. The address scheme is not decoration. A student who has learned that the injection point is on a specific port can practise it, and an instructor can write an exercise that says go to a particular address without a discovery phase, which is what makes a class of two hundred people possible.

One container per vulnerability class, each on its own port

The custom labs are the part of the project that a standard vulnerable application set would not give you, and the table in the README lists them with a port and a vulnerability type. hydra-nexus on port 5010 is a multi-vulnerability gauntlet covering SQL injection, XSS, IDOR and XXE among others. phantom-script on 5011 covers cross-site scripting in its reflected, stored and DOM forms, and trojan-relay on 5012 is a server-side request forgery target. sqli-breach on 5001 is SQL injection and shell-inject on 5002 is OS command injection. maze-walker on 5003 is path and directory traversal, entity-smuggler on 5013 is XML external entity injection, token-tower on 5020 is a JWT vulnerability, render-reign on 5021 is server-side template injection, and deserial-gate on 5022 is insecure deserialization. The last three extend the range into newer territory: redis-rogue is a DEF CON 31 challenge with no separate port listed, graphql-galaxy on 5023 covers GraphQL introspection and IDOR, and proto-pollute on 5004 covers prototype pollution and DOM clobbering. The labs are built from the additional-labs/ directory in the repository, which means the instructor can read the source of every target and modify it, and the exercises can be adjusted to a class's needs.

Setting it up takes a virtual machine and a lot of disk

The install path is deliberately conservative, and the README tells you to start with a virtual machine rather than on your own machine. You download and install Kali Linux or Parrot OS in a VM using the hypervisor of your choice, with VirtualBox, VMware Workstation or Fusion, KVM and Proxmox all named. The minimum requirements are 8 GB of RAM, 2 vCPUs and 50 GB of disk space, and there is a tip to make sure virtualization is enabled in the system BIOS for the best performance. With the VM ready, the install is three commands.

git clone https://github.com/The-Art-of-Hacking/websploit.git
cd websploit
sudo bash install.sh

The script installs all the necessary tools, sets up Docker, deploys the intentionally vulnerable containers and adds the thousands of cybersecurity resources. The repository also carries a Vagrantfile, an install.sha file, a containers.sh, a vulnhub.sh and a websploit-containers.drawio file for the network diagram, so the environment can be provisioned in more than one way.

Bringing the lab up and taking it down again

Once installed, the day to day operation is Docker Compose, and the README gives the commands for the whole life cycle of a session.

# Start all containers
docker compose up -d

# Start with build (for additional labs)
docker compose up -d --build

# View running containers
docker compose ps

# View logs
docker compose logs -f [container_name]

# Stop all containers
docker compose down

# Rebuild specific containers
docker compose build --no-cache [container_name]

The build flag exists because the custom labs are built locally rather than pulled, so a first run needs the images built, and a later run that only starts the published ones does not. The logs command with a container name is the one an instructor will use most, since a student reporting a broken lab almost always means one container did not start. The compose file also sets restart to unless-stopped on every service, so a container that dies comes back, and each service declares its platform explicitly, which is the detail that causes the next problem.

Apple Silicon is the rough edge, and the fix is Rosetta

The troubleshooting section is unusually specific, and it is about the hardware rather than about the labs. Several containers, and the README names webgoat, dvwa, galactic-archives, gravemind, y-wing and redis-rogue, are configured to run as linux/amd64, so on an ARM64 host they run under emulation. Most work, but some do not, and the one named is y-wing, whose Go binaries crash under QEMU user-mode emulation with errors like runtime: lfstack.push invalid packing and fatal error: lfstack.push. The README is careful to say this is a known incompatibility between Go's runtime pointer packing and QEMU's x86-on-ARM emulation, and that it is not a configuration bug in the repository, pointing at issue 82 for the discussion. The recommended fix for Apple Silicon users is to run Docker Desktop directly on macOS rather than Docker inside a Kali ARM VM, so the amd64 emulation goes through Apple's Rosetta 2, which handles Go binaries reliably. That means enabling the Virtualization framework and the Rosetta setting for x86/amd64 emulation in Docker Desktop, then restarting it, and only then running docker compose up -d. The compose file repeats the same warning in a comment on the y-wing service and lists the other routes, an x86_64 host or skipping that service.

How this compares with running a single vulnerable app

There are three other ways to teach application security hands on, and each trades something away. Running one deliberately broken application on its own, which is what most OWASP training targets are designed for, is the lightest option and it works well for a workshop of a dozen people, but it teaches one class of bug at a time and the class has to agree on which application to use. A shared range of vulnerable hosts over a network, which is the model of a capture the flag or a cyber range, gives students the same infrastructure and the same addresses, and it is more work to provision and to keep patched. And a commercial training platform does the same thing with support, a maintained catalogue and a per learner cost, which is why institutions buy them. WebSploit Labs sits in the middle of those. It is a cyber range in the sense that the addresses are fixed and the topology is documented, and it is a course kit in the sense that the exercises, the labs built around each vulnerability class and the resource library all come from one author. The licence is the point to read before you use it, since the compose file carries an SPDX header of GPL-3.0-or-later and states that additional terms under GNU GPL version 3 section 7 are in the COPYRIGHT file, so a school redistributing the lab images to its own students should read that file rather than assume the standard GPL text covers it.

Editorial conclusion

WebSploit Labs suits a security instructor who needs every student to have the same set of deliberately broken applications in front of them without touching anything on the internet, because the compose file pins container names, images and IP addresses so the exercises can refer to a fixed address. It is the wrong tool for a lone learner who wants one vulnerability to practise, since the setup asks for a virtual machine with 8 GB of RAM and 50 GB of disk, and it is the wrong tool for any assessment of a real system, because every application in it is broken on purpose. Before you stand this up, read the ARM64 troubleshooting section, since the amd64 containers will run under emulation on Apple Silicon and one of them crashes, and read the COPYRIGHT file, because the compose file states that additional terms apply under GPL version 3 section 7.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. The-Art-of-Hacking/websploit on GitHub