One day, I received a message from an old friend who isn’t particularly tech-savvy. He asked me to follow a link and vote for some girl named Vika.
Yeah, yeah. Exactly the kind of stuff people were doing on Odnoklassniki ten years ago.
The interesting part was that the girl he was supposedly voting for was actually someone he knew. He had even seen her recently. So nothing seemed suspicious to him. He clicked the link and granted the requested access without a second thought.
Something felt off, so I contacted him through another social media platform.
It turned out that he had already been locked out of his Telegram account for several days and couldn’t recover access. According to him, the login verification codes simply weren’t arriving.
At first, I thought: There’s no way.
Surely there must be alternative ways to log in. Maybe he just didn’t understand the interface or had missed some button.
But no.
I opened Telegram myself, entered his phone number into the login screen, and received a message saying that a verification code couldn’t be sent because the request limit had been exceeded.
And that’s where this story gets much more interesting than your typical phishing incident.
When Security Starts Working Against the Account Owner
We essentially ended up with the following situation:
An attacker had compromised my friend’s Telegram account, while the legitimate owner had lost access to his active sessions.
Meanwhile, attempts to log back in were being blocked by a security mechanism known as rate limiting.
For anyone unfamiliar with the term, rate limiting is a mechanism that restricts the number of requests allowed within a certain period of time. It’s commonly used to protect against brute-force attacks, automated abuse, spam, and other malicious activities.
On its own, rate limiting is perfectly normal and absolutely necessary.
But here’s the question:
What happens if an attacker deliberately exhausts the authentication rate limits associated with someone else’s phone number?
You end up with a rather absurd situation.
The attacker is already inside the account and can continue using an authenticated session, sending phishing messages, and interacting with the victim’s contacts.
Meanwhile, the actual account owner, who still controls the phone number, can’t even receive a verification code to log in.
A mechanism designed to protect the user effectively starts working against them.
In our case, I couldn’t determine who had exhausted the limits. It could have been the attacker, or it could have been the legitimate owner repeatedly trying to regain access.
But the outcome was exactly that: someone else continued using the account while its rightful owner couldn’t log in.
What Surprised Me About Telegram’s Rate Limiting
What bothered me most was that the restriction appeared to be associated with the phone number rather than just the specific device attempting authentication.
My friend had already tried logging in himself. When I repeated the process from my own device, I received the same rate-limit error.
This doesn’t necessarily prove that Telegram calculates its limits exclusively by phone number. We don’t know the internal implementation of its authentication system.
However, the observed behavior suggests that the restriction affected login attempts across different devices.
And that raises another question.
Why didn’t the system offer us an alternative way to verify account ownership once the limit had been reached?
For example, Meta’s ecosystem provides various authentication and account recovery methods, including SMS, WhatsApp, and other verification mechanisms, depending on the service and circumstances.
In our case, Telegram didn’t offer any accessible alternative that would allow us to get around the restriction.
This means that simply having access to your SIM card doesn’t necessarily guarantee that you can recover your account when you need to.
Of course, alternative authentication channels also need protection against abuse. But having no accessible recovery option in a situation like this seems like a questionable design decision.
What If the Attacker Doesn’t Even Need Access to Your Account?
Now let’s imagine a slightly different scenario.
You have a Telegram account that you haven’t used in a long time. You no longer have any active sessions, but you still own the phone number associated with it.
What if someone starts systematically initiating login attempts using your phone number, deliberately triggering the authentication rate limits?
If these limits can be exhausted and repeatedly maintained through additional requests, this could potentially create a Denial of Service (DoS) scenario targeting the authentication process itself.
And the interesting part?
The attacker theoretically wouldn’t even need to compromise your account first.
Knowing your phone number could be enough.
There is, however, an important caveat: we don’t know whether Telegram’s internal protections actually allow such restrictions to be maintained indefinitely.
The platform may use additional checks, different rate-limit windows, and other safeguards that prevent this behavior.
So, at this point, this is a hypothesis rather than a confirmed vulnerability.
Nevertheless, the possibility itself is worth investigating.
Now Let’s Combine Both Scenarios
Imagine an attacker has already compromised someone’s Telegram account through phishing.
They terminate the victim’s active sessions, assuming they have the necessary permissions to do so.
The legitimate owner then attempts to log back in.
But they can’t.
The authentication request limit has been exceeded.
If the attacker can deliberately keep that restriction active, they gain an additional mechanism for maintaining control over the compromised account.
And here’s the most concerning part: the attacker and the legitimate owner are not operating under the same conditions.
The attacker doesn’t need to authenticate again because they already have an active session.
The legitimate owner, however, must authenticate to regain control.
Every additional hour during which the owner cannot recover access gives the attacker more time to exploit the compromised account.
They can send messages to contacts, distribute phishing links, impersonate the victim, and potentially compromise additional accounts.
At that point, the problem extends far beyond a single stolen account.
So What’s the Actual Problem?
I don’t think rate limiting is a bad security mechanism.
Quite the opposite. Without it, modern authentication systems would be significantly more vulnerable to automated attacks and abuse.
But security mechanisms shouldn’t be evaluated solely by how effectively they prevent unauthorized access.
They should also be evaluated by what happens when a legitimate user needs to recover an already compromised account.
Ideally, an authentication system should accomplish two things simultaneously:
Prevent attackers from requesting unlimited verification codes, while ensuring that those restrictions cannot be weaponized to lock out the legitimate account owner.
In my friend’s case, we encountered a situation where a mechanism designed to prevent abuse became an obstacle to recovering access.
And although we don’t have enough evidence to conclude that the attacker was deliberately manipulating the rate limits, the incident raises an interesting question about Telegram’s authentication architecture.
How secure is an account recovery system if its own protective restrictions can potentially be used against the account owner?
After all, security isn’t just about keeping unauthorized people out of an account.
It’s also about making sure the rightful owner can get back in when someone else has already taken control.