Intro One lazy afternoon back in high school, I was browsing OLX, a Craigslist-like site, on my computer and decided to create an account. To my surprise, the site had changed its login policy and now required a phone number. Since my phone was in another room and, being the lazy person I am, I did not feel like going to get it, I entered my number and started mashing the keyboard on the verify-code page until a rate limit was triggered . But I noticed an unusual message , so I finally went to get my phone for the story to really begin. So far, nothing special. The flow looked normal. I had tried enough wrong codes, the site responded with a “try again later” message, and that should have been the end of the story. But before I went to grab my phone, I noticed something unusual in the way the page responded. It was one of those tiny details that is easy to ignore if you are not paying attention, and impossible to unsee once you are. The lockout was there. The weird part was that the page still had opinions about the code I entered. What Was That? I finally went to the other room, grabbed my phone, read the legitimate SMS code, and typed that exact code into the page while the rate limit was still active. The strange message disappeared. Then I entered a wrong code again, and the message came back. I repeated that a few times just to make sure I was not imagining it. Every time the code was wrong, the page showed both the lockout banner and the invalid-code signal . Every time the code was right, the page kept the lockout banner but dropped the invalid part. That was the moment the bug became clear. The site was supposed to be done talking after the lockout kicked in. Instead, it kept leaking whether the submitted OTP was correct . The screen still looked blocked. It just stopped looking wrong. On a wrong submission, the page showed both the lockout banner and the invalid-code signal. In simpler terms, the flow looked like this: You enter an invalid code: the page says the code is invalid. You enter enough invalid codes: the page says try again later, but still says the code is invalid. You enter the correct code right after that: the page still says try again later, but the invalid-code signal disappears. That meant the lockout state was not neutral at all. It was still giving away the answer. Play it Tiny lockout simulator Three wrong tries trigger the lockout. Then hit Go get phone and submit the real code. The broken part is the same one from the story: the lockout stays, but the invalid-code signal disappears. Totally serious verification lab SMS Phone Verification Incorrect code Too many attempts. Please try again later. Correct code before lockout. Boring, secure-looking outcome. Phone status: still in the other room. Enter a 4-digit code Submit Mash keyboard Go get phone Reset Goal: hit the lockout first, then come back with the real code. Wrong tries used: 0 / 3 Where the bug lives Verification-code screen signup, login verification, or password reset Wrong code entered a few times application switches into lockout Expected secure behavior every blocked submission should look the same BUT IN REALITY Wrong code during lockout lockout message stays visible invalid-code signal stays visible Correct code during lockout lockout message stays visible invalid-code signal disappears Bug: locked state still leaks correctness The real issue was not one screen. It was the verification-code logic itself , reused across signup, phone verification, 2FA-style checks, password reset , and the rest of the account flow. The cleaner proof lives in the response difference: wrong codes keep the invalid marker, while the correct code removes it even during lockout. Why the bug was exploitable: code expiry? not really. There were really two flaws here, and they worked together perfectly. The first flaw was that I could still tell whether the submitted code was right or wrong even after the rate limit was active. The second flaw was that the verification code stayed valid long enough for that leaked signal to matter. The “try again later” state lasted about seven minutes , which was more than enough time to use the leak. On its own, a correctness signal is already bad. But a correctness signal plus time turns into an attack path. A lockout is supposed to make the application boring. Once the site decides you have tried too many times, every blocked response should look equally useless. Here, it didn’t. The site kept answering the only question that mattered. That becomes much more severe once you stop thinking only about signup or one phone-verification page and start thinking about every place the same code flow might be reused. If that exact behavior is sitting behind login verification, 2FA-style prompts, password reset, and account recovery, then you are no longer looking at one quirky screen. You are looking at a system-wide verification flaw. A real lockout does not just block attempts. It stops revealing success and...