CAPTCHA bypass is still a thing in 2026

Posts are delayed for months or sometime a year at a time to ensure vulnerabilities I post are fixed.

Oh mein gott, guys it's been forever since I lasted my last write up, life had been hectic. Took another role elsewhere, but I didn't align with my personal goals, so I settled back to an Individual Contributor as a lowly and pesky tester. To celebrate my no-longer-too-stressed life, I brought you "CAPTCHA bypass is this still a thing in 2026", spoiler alert: yes it's that simple.

Before we start, there are a few things I'd like you to know before you start complaining:

• No, on its own this is not a vulnerability (per-se), it is an intended function of what registration pages are supposed to be.
• No rate limiting adds impact of this misconfiguration.
• To solve this, add rate limiting AND validate CAPTCHA token on every request rather than relying on a specific parameter.

OK, so a few months ago I was doing a test for a company who has account enrollment page open. When a normal user tries to create a an account using a regular workflow, the application will prompt the user to complete a Google CAPTCHA prompt to complete.

When you go through this CAPTCHA prompt and select "verify", the application will then send a request to the server containing the new user enrollment information, along with CAPTCHA token for that session, and a "ReCaptchaValidated:false" parameter.

Ok now at this point you should know where this is going. Like any L33T Hax0rs would do, I sent this request to my repeater. BUT, when you actually send the same request again with a different username, you will get a 401 unauthorized. Changing this value from "false" to "true" will bypass this CATPCHA, give you a 200 OK response, allowing anyone to flood the application server with arbitrary accounts, filling up its database.