Fastest Safe Start: Run OWASP Mutillidae II with Docker Compose

The most valuable information belongs first: for most learners, the official pre-built Docker Compose stack is the fastest route. It brings up the web application, MySQL, OpenLDAP, phpMyAdmin, and phpLDAPadmin together, which avoids many native PHP and database compatibility problems.

Copy-and-paste quick start

git clone https://github.com/webpwnized/mutillidae-dockerhub.git
cd mutillidae-dockerhub
docker compose up -d

docker compose ps
curl http://127.0.0.1/set-up-database.php

Open http://127.0.0.1/. If that port is already occupied, try http://127.0.0.1:8080/. The official stack exposes the Mutillidae HTTP interface on ports 80 and 8080, HTTPS on 443, phpMyAdmin on 81, phpLDAPadmin on 82, and LDAP on 389.

Stop the lab when you finish

docker compose down

Use docker compose down -v only when you intentionally want to remove the lab's persistent volumes and start over. The -v option is destructive to the Compose-managed data.

What Is OWASP Mutillidae II?

OWASP Mutillidae II is a free, open-source, deliberately vulnerable PHP application maintained for web-security education. The official project describes it as a target for labs, classrooms, capture-the-flag exercises, security enthusiasts, and vulnerability-assessment tools. It includes more than 40 vulnerabilities and challenges, built-in hints and tutorials, secure and insecure modes, and a one-click reset capability.

The lab covers generations of the OWASP Top 10 and includes examples related to injection, cross-site scripting, authentication, authorization, file handling, information exposure, and web-service behavior. That breadth makes it useful for beginners, but the best learning comes from a disciplined process: establish a baseline, change one input, observe evidence, identify the root cause, and write down the secure implementation.

Current project status checked in July 2026

On July 13, 2026, the official source repository's version file reported 2.12.7, and the official Docker Hub repository also listed the www-2.12.7 image tag. Versions can change, so verify the repository version file and Docker tags before publishing a tutorial or pinning a classroom image.

OWASP Mutillidae II Download: GitHub, Docker and the SourceForge.net Question

Readers searching for an OWASP Mutillidae II download often encounter several generations of links. The active project source is on GitHub, while the official OWASP page links to the main source repository, Docker build repository, DockerHub Compose repository, Docker Hub images, and tutorial channel.

What about “OWASP Mutillidae II download SourceForge.net”?

SourceForge results still appear in searches because older Mutillidae packages were distributed there. However, the maintained source has moved to GitHub. Do not assume an old SourceForge ZIP or a third-party mirror is current merely because it ranks highly. Compare the package version, repository activity, and checksum information, and prefer the links published by OWASP and the active maintainer.

Verify what you downloaded

git clone https://github.com/webpwnized/mutillidae.git
cd mutillidae
cat version
git remote -v
git log -1 --oneline

This small check records the source origin, current project version, and commit used for your lab. Include those details in an OWASP Mutillidae II writeup so another reader can reproduce the same behavior.

OWASP Mutillidae II Docker Tutorial

The project offers two official Docker paths. Use pre-built images when speed matters, or build locally when container internals are part of the lesson. Both approaches create a multi-container environment rather than a single isolated PHP container.

Option A: Pre-built Docker images with Compose

git clone https://github.com/webpwnized/mutillidae-dockerhub.git
cd mutillidae-dockerhub

docker compose pull
docker compose up -d
docker compose ps

Option B: Build the official containers from source

git clone https://github.com/webpwnized/mutillidae-docker.git
cd mutillidae-docker

docker compose -f .build/docker-compose.yml up --build --detach
docker compose -f .build/docker-compose.yml ps

The build repository documents five containers: the Mutillidae web application, MySQL database, phpMyAdmin, OpenLDAP, and phpLDAPadmin. It also documents the initial database build endpoint at http://127.0.0.1/set-up-database.php.

Useful operational commands

# See container state
docker compose ps

# Follow recent logs
docker compose logs --tail=100 -f

# Show published ports
docker ps --format "table {.Names}	{.Ports}	{.Status}"

# Restart the stack
docker compose restart

# Stop and remove containers while preserving named volumes
docker compose down

Update a pre-built Compose installation

git pull --ff-only
docker compose pull
docker compose up -d
docker compose ps

Before upgrading a class or shared lab, record the current Git commit and image tags. Lesson text, page paths, database content, and expected results can change between versions, which is why a writeup should always state its tested version.

How to Install OWASP Mutillidae II on Windows

For Windows 10 or Windows 11, Docker Desktop with the WSL 2 backend is usually the cleanest approach. It keeps the application stack reproducible and avoids manually matching Apache, PHP, and MySQL versions.

Recommended Windows method: Docker Desktop

1. Install Docker Desktop from the official Docker documentation and start it.
2. Confirm that Docker is running from PowerShell.
3. Clone the official Compose repository.
4. Start the containers and initialize the database.
5. Open the application only from the same Windows machine.

docker version
docker compose version

git clone https://github.com/webpwnized/mutillidae-dockerhub.git
Set-Location mutillidae-dockerhub

docker compose up -d
docker compose ps

Invoke-WebRequest http://127.0.0.1/set-up-database.php -UseBasicParsing

Then open http://127.0.0.1/ or http://127.0.0.1:8080/. If PowerShell reports that git is missing, install Git for Windows or download the repository ZIP from GitHub, extract it, open PowerShell in that directory, and run the Compose commands.

Legacy Windows method: XAMPP source installation

Native XAMPP installation remains possible, but it is more sensitive to PHP extensions, database settings, file permissions, and version differences. The source repository notes that the application code lives under src, so copying the repository root directly into the web directory is a common mistake.

git clone https://github.com/webpwnized/mutillidae.git C:\lab\mutillidae-source
New-Item -ItemType Directory -Force C:\xampp\htdocs\mutillidae
Copy-Item -Recurse -Force C:\lab\mutillidae-source\src\* C:\xampp\htdocs\mutillidae\

Start Apache and MySQL from the XAMPP control panel, then browse to http://127.0.0.1/mutillidae/. Use the application's setup or reset function to initialize the database. When a native installation fails, compare PHP modules, database connectivity, Apache logs, and the current repository documentation before changing application files.

How to Install OWASP Mutillidae II on Kali Linux

Kali Linux is a natural place to run training labs, but the same isolation rules apply. A virtual machine using NAT or host-only networking is preferable to a bridged interface on a shared network. Kali's official documentation also warns that the package named docker is not the container engine; the distribution package is named docker.io.

Recommended Kali method: Docker in an isolated VM

sudo apt update
sudo apt install -y docker.io docker-compose git
sudo systemctl enable --now docker

sudo docker version
sudo docker-compose version

git clone https://github.com/webpwnized/mutillidae-dockerhub.git
cd mutillidae-dockerhub
sudo docker-compose up -d
sudo docker-compose ps

curl http://127.0.0.1/set-up-database.php

Package names can change across Kali rolling releases. The current Kali rolling repository provides a docker-compose package. If your system instead uses Docker's Compose plugin, use docker compose in place of docker-compose. Avoid installing the unrelated package named simply docker.

Optional non-root Docker use

sudo usermod -aG docker "$USER"
newgrp docker
docker ps

Membership in the Docker group effectively grants root-level control over the host. Use it only on a personal lab machine where that tradeoff is understood. Continuing to use sudo docker is acceptable for a short-lived training VM.

Legacy Kali LAMP installation

Docker is preferred, but a source installation is useful when the learning goal includes Apache, PHP, and database configuration. The following creates a local copy under Apache's document root. Exact PHP package names can vary across Kali releases.

sudo apt update
sudo apt install -y apache2 mariadb-server php php-mysql php-curl php-xml php-mbstring git
sudo systemctl enable --now apache2 mariadb

git clone https://github.com/webpwnized/mutillidae.git /tmp/mutillidae-source
sudo mkdir -p /var/www/html/mutillidae
sudo cp -a /tmp/mutillidae-source/src/. /var/www/html/mutillidae/
sudo chown -R www-data:www-data /var/www/html/mutillidae

curl -I http://127.0.0.1/mutillidae/

Open http://127.0.0.1/mutillidae/, use the setup function, and consult Apache and MariaDB logs if initialization fails. Do not weaken the whole Kali system merely to make a legacy PHP setting work; use Docker instead when package compatibility becomes the main obstacle.

First Run: URL, Database Setup, Login and Safe Lab Settings

The first successful page load is not the end of setup. A useful lab session starts by confirming the URL, database state, security level, reset controls, and account handling.

Optional local hostname mapping

The Docker documentation notes that the site may assume the hostname mutillidae.localhost. Modern systems often resolve *.localhost automatically, but a hosts-file entry can make behavior explicit.

# Linux or macOS hosts file entry
127.0.0.1 mutillidae.localhost

# Windows hosts file entry
127.0.0.1 mutillidae.localhost

After saving the entry with administrator privileges, open http://mutillidae.localhost/. Keep the mapping local; do not point a public DNS name at the vulnerable lab.

OWASP Mutillidae II Walkthrough: A Repeatable Method That Teaches More Than an Answer Key

A good walkthrough is not a list of payloads. It is a reusable investigation process that explains what changed, why the result matters, and how the application should be fixed. This method works across injection, cross-site scripting, authentication, authorization, file handling, and web-service lessons.

Beginner-friendly first session

1. Start the Docker stack and initialize the database.
2. Open the application and identify the current security level.
3. Choose one introductory lesson from the OWASP Top 10 menu.
4. Read the lesson description before touching the input.
5. Submit a normal value and capture the baseline.
6. Use the first built-in hint and make one controlled change.
7. Explain the observed result in plain language.
8. Switch to secure mode and repeat the same request.
9. Reset the lab, reproduce the result once more, and save the evidence.

A safe SQL injection learning sequence

Mutillidae II includes injection lessons, but a useful tutorial should keep the activity inside the local training application and focus on the reasoning process. Start with a normal lookup, identify which input reaches a database operation, use the built-in hint, compare the application's response, and then inspect how parameterized queries or prepared statements change the result in secure mode.

For broader context, compare the lab behavior with the OWASP Top 10 vulnerabilities guide. The same discipline applies to modern APIs: input handling matters, but object authorization, business flows, response data, and token behavior must also be tested.

OWASP Mutillidae II Writeup and Solutions Template

Searchers often want “OWASP Mutillidae II solutions,” but a static list of answers ages quickly and can hide the lesson. A better solution page gives readers a structured worksheet that they can reuse, compare, and improve.

Copy-and-paste lab writeup template

Lab title:
Mutillidae version:
Git commit or Docker image tag:
Date tested:
Lab URL:
Security level:
Authorization boundary: Local isolated lab only

Objective:
What behavior is this lesson designed to demonstrate?

Baseline request:
Method:
Path:
Parameters:
Authentication state:
Expected normal result:

Controlled change:
Which single input changed?
Which built-in hint guided the test?

Observed evidence:
Status code:
Response difference:
Data or behavior exposed:
Screenshot or request reference:

Root cause:
Which trust assumption or implementation flaw caused the result?

Secure-mode comparison:
What changed after enabling the stronger control?

Remediation:
Code-level fix:
Design-level fix:
Validation or authorization requirement:
Logging and monitoring signal:

Retest result:
Did the same request fail safely after remediation?

What a high-quality solution should contain

Make the page worth returning to

Keep a compact “next session” checklist beside the writeup. Before closing the lab, save the version, lesson, security level, baseline, key evidence, unanswered question, and next test. At the next session, restart from those facts rather than repeating the entire setup.

Next session checklist
[ ] Confirm the same Mutillidae version
[ ] Start the isolated Docker stack
[ ] Verify the database state
[ ] Set the documented security level
[ ] Reproduce the baseline request
[ ] Repeat the last controlled change
[ ] Compare secure-mode behavior
[ ] Add one remediation test
[ ] Stop the lab when finished

OWASP Mutillidae II Troubleshooting Guide

Minimal diagnostic bundle

docker compose ps
docker compose logs --tail=200
docker ps --format "table {.Names}	{.Image}	{.Ports}	{.Status}"
curl -I http://127.0.0.1/
curl -I http://127.0.0.1:8080/

Save this output with the operating system, Docker version, Compose version, Git commit, and a description of the last successful step. That information is more useful than a screenshot of a generic error page.

Common OWASP Mutillidae II Tutorial Mistakes

• Exposing the lab: publishing ports to a public interface, cloud security group, router, or shared network.
• Using outdated downloads: following an old SourceForge or third-party package without checking the active GitHub project.
• Copying the wrong directory: placing the repository root in XAMPP instead of the application content under src.
• Skipping the baseline: trying unusual inputs before understanding normal application behavior.
• Ignoring the security level: reproducing a result without documenting whether the lab was insecure or secure.
• Reusing real credentials: entering a personal password, email, token, or secret into an intentionally vulnerable application.
• Deleting volumes too early: destroying evidence before reading container logs and checking database health.
• Treating a payload as the lesson: recording what worked without explaining the root cause and remediation.
• Using old writeups as truth: assuming page names and expected results are identical across versions.
• Leaving the lab running: forgetting to stop containers after the exercise.

Related API Security Topics to Consider

Mutillidae II is primarily a vulnerable web application, but the investigation habits transfer directly to APIs. The same request can look harmless at the network layer while exposing sensitive data, bypassing object-level authorization, abusing a business flow, or leaking a token in the response. That is why secure development testing and runtime visibility solve different parts of the problem.

To extend the lab into a broader program, compare API security testing versus runtime monitoring. Testing can find reproducible weaknesses before release, while runtime monitoring sees real traffic, changing clients, schema drift, abuse sequences, and attacks that depend on production context.

Object and workflow lessons connect naturally to BOLA and IDOR API security and business logic abuse detection. A runtime program also needs API runtime visibility and an API security incident response playbook so findings become prioritized evidence rather than isolated alerts.

API security evaluation checklist

Which Installation Path Should You Choose?

Official Resources Used for This Guide

• OWASP Mutillidae II project page
• OWASP Mutillidae II main GitHub repository
• Official pre-built Docker Compose repository
• Official Docker build repository
• Official Mutillidae II Docker Hub repository
• Kali Linux Docker installation guidance

Project versions, package names, Docker tags, and operating-system requirements can change. Verify the current official documentation before using these instructions in a classroom, certification lab, company training environment, or published technical standard.

Conclusion

OWASP Mutillidae II is most valuable when it becomes a repeatable learning system rather than a collection of isolated answers. Use the official GitHub and Docker resources, run the application only in a controlled local environment, initialize and reset it deliberately, record the version and security level, capture a normal baseline, change one input at a time, and finish every walkthrough with a secure-mode retest and specific remediation.

For most readers, the best route is clear: start with the official DockerHub Compose repository, keep the stack inside an isolated machine, use the built-in hints before external answer keys, and maintain a structured writeup that explains evidence and fixes. That approach remains useful even after the exact lesson or version changes.

OWASP Mutillidae II FAQ