Hello Hackers— I'm Abdelrahman Fathy. I'm a passionate bug hunter and penetration tester who loves exploring web applications and breaking things to make them safer. In this writeup, I present a race condition discovered in the login flow of a website that allowed bypassing the account lockout and rate-limit mechanism.
How I discovered The Bug:
While testing a target in an external bounty program, I started where I always do — with the authentication endpoints. I followed the usual flow: submit a wrong password, fail, repeat. After the fifth failure the account was blocked, as expected. That's when curiosity kicked in. I wasn't satisfied with "it blocks after five" — I wondered: what if I don't send attempts one after another? What if I fire a bunch of requests at the same time?
So I set up Burp Repeater, duplicated the same login request dozens of times, and hit Send in Parallel. Instead of being blocked, multiple parallel attempts were processed — one with the correct password returned a valid session and user data.
Observed Results:
- The account lockout was effectively bypassed when I sent simultaneous login requests.
- Multiple authentication attempts were processed past the configured 5-attempt threshold — in my tests, I was able to perform multiple attempts within a short window.
- Some parallel requests were treated like normal attempts instead of being blocked, meaning the failure counter wasn't being enforced atomically.
Impact:
- Attackers can bypass the rate limit and perform large-scale brute-force attacks against user accounts.
- Significantly raises the chance of account takeover and unauthorized access to sensitive user data.
- Renders the implemented protection (5-attempt lockout) ineffective against automated or parallel login attempts.
Remediation recommendations:
- 𝐂𝐞𝐧𝐭𝐫𝐚𝐥𝐢𝐳𝐞 𝐚𝐭𝐭𝐞𝐦𝐩𝐭 𝐜𝐨𝐮𝐧𝐭𝐢𝐧𝐠: Ensure failed attempts are recorded atomically in a centralised datastore (e.g., server-side database with atomic increment, Redis with INCR and TTL, etc.).
- 𝐔𝐬𝐞 𝐬𝐞𝐫𝐯𝐞𝐫-𝐬𝐢𝐝𝐞 𝐥𝐨𝐜𝐤𝐬 𝐨𝐫 𝐭𝐫𝐚𝐧𝐬𝐚𝐜𝐭𝐢𝐨𝐧𝐬: Prevent race conditions by serializing updates to attempt counters (e.g., use DB transactions or distributed locks).
- 𝐔𝐬𝐞 𝐬𝐞𝐜𝐨𝐧𝐝𝐚𝐫𝐲 𝐚𝐧𝐭𝐢-𝐚𝐮𝐭𝐨𝐦𝐚𝐭𝐢𝐨𝐧 𝐜𝐨𝐧𝐭𝐫𝐨𝐥𝐬: CAPTCHAs after several failed attempts, progressive delays, and multi-factor authentication enforcement.
Alhamdulillah, I'm glad to share that my report has been successfully accepted by the external program.
Conclusion: And that's it, folks! I hope this write-up gives you useful insight. Quick tip before you go: always look for what the system says "no" to — then ask yourself whether you can make it say "yes" using the simplest possible scenario. Often the smallest change or the tiniest timing difference is enough to expose a logic flaw. Thanks for reading — if you have questions or want the PoC files, ping me. Happy bug hunting!
𝐌𝐲 𝐋𝐢𝐧𝐤𝐞𝐝𝐢𝐧: https://www.linkedin.com/in/abdelrahman-fathy-9242b4278