How Hackers Brute Force Modern Login Pages — 5 Real Bypasses (2026)

Bypass 1 — Rate Limit via IP Header Injection

Rate limiting should track failed attempts by account, not by IP. But a lot of implementations track by source IP — because it’s simpler to implement. That implementation choice creates the bypass: if the application respects the X-Forwarded-For header as the source IP, rotating that header value resets your attempt counter.

The test takes two minutes. Add an X-Forwarded-For header with a fake IP to your login request. Confirm the application accepts it (no error). Then change the IP value and retry a failed attempt — does the failed attempt counter reset? If yes, the rate limiting is bypassable by anyone who can send custom headers. In Burp Intruder, use a Pitchfork attack type with one payload on the password field and one on the X-Forwarded-For value.

Bypass 2 — CAPTCHA Token Reuse

Most developers implement CAPTCHA by integrating Google reCAPTCHA or hCaptcha and checking that the response token is valid. What many don’t implement: checking that the token hasn’t been used before. A valid solved token should be single-use. If the server accepts the same token on multiple requests, CAPTCHA provides no protection against automated testing — you solve it once manually and replay that token indefinitely.

The test is trivial. Solve the CAPTCHA once normally, capture the g-recaptcha-response parameter in Burp, and replay the login request with that same value multiple times. If subsequent requests succeed despite the token being “used,” token reuse is confirmed.

Bypass 3 — Username Enumeration via Timing

Before brute-forcing anything, you want to know which usernames exist. The most reliable enumeration technique that survives normalised error messages is timing analysis. When you submit a valid username with a wrong password, the application does a database lookup, finds the account, then checks the password — that takes measurable time. When you submit an invalid username, the application either skips the password check or returns immediately — slightly faster.

The timing difference is often only 50-200ms, but it’s consistent. Run Burp Intruder with a username wordlist, constant wrong password, and sort results by response time. Valid usernames cluster at one timing band, invalid ones at another. On large user populations this gives you a confirmed valid username list before you attempt a single password.

Bypass 4 — Account Lockout Logic Flaws

Account lockout is often implemented with subtle logic errors. The most common: lockout per IP, not per account — already covered in Bypass 1. The second most common: the lockout counter doesn’t reset correctly. Test whether a correct password attempt resets the lockout counter, or whether it persists regardless of correct attempts in between. A counter that resets on any successful interaction (not just the same account) creates a bypass: alternate between correct and wrong passwords with the counter never reaching the threshold.

The most complete chain I’ve documented on a real engagement: timing analysis confirmed 340 valid usernames from a company’s login page. X-Forwarded-For rotation bypassed the 10-attempt rate limit. CAPTCHA token reuse eliminated the CAPTCHA layer entirely. Credential stuffing from a 2022 breach database against the valid username list returned 11 working account credentials. Six of those accounts had no MFA because they were contractor accounts the IT team had deprioritised in the MFA rollout. That’s a complete path from zero knowledge to eleven authenticated sessions — every step enabled by a different bypass finding, each one Medium-rated individually, collectively Critical. The report structure that got it triaged as Critical immediately: a numbered attack chain table showing exactly which bypass enabled which step, with the full impact at the bottom. Individual findings submitted separately would have been five Medium payouts. Submitted as a chain with documented impact: one Critical.

Password spraying is the anti-lockout technique. One password per account. Lockout triggers after N failed attempts per account. With one attempt per account, no individual account ever reaches N. Against an organisation with 500 employees, testing password “Summer2026!” against all 500 accounts triggers zero lockouts while finding anyone using that exact password.

Bypass 5 — MFA OTP Rate Limiting Absence

Here’s the MFA implementation flaw I find most consistently: rate limiting exists on the username/password form, but not on the OTP entry form. The developer secured the first step thoroughly and forgot the second step is also a brute-force surface. A 6-digit TOTP has 1,000,000 possible values. With no rate limiting on OTP entry, you can brute force it in under two minutes with automated requests.

The test: get past the first authentication step with valid credentials (your own test account), arrive at the OTP entry form, and send that form submission to Burp Intruder. Load a 6-digit number sequence as the payload. Start the attack and watch the response lengths. Any response with a different length from the “wrong OTP” baseline indicates a valid OTP or a different error — investigate it.

Chaining: Enumeration + Bypass = Account Takeover

Individual authentication bypass findings rate Medium in most programmes. Chain them together and you’re at Critical. Here’s the chain I’ve demonstrated on real engagements: timing enumeration gives you a list of valid usernames → rate limit bypass via X-Forwarded-For gives you unlimited attempts → credential stuffing with breach data against those valid usernames → account takeover.

None of those individual findings is Critical in isolation. Together, the attack path goes from “I know nothing about the application” to “I have account access” without triggering a single protection. That’s the bug bounty report structure that generates Critical payouts: not one finding, but a documented chain with each step and the cumulative impact.