Bugs and Suggestions

I support a secure, non-destructive recovery route for legitimate owners after all sessions are revoked. Please also consider recovery availability when login attempts are rate-limited: clear retry guidance, an escalation route, and a separately bounded recovery allowance for users presenting strong pre-existing ownership evidence that unrelated requests cannot exhaust. Retain protections against SIM swaps, brute force and IP rotation; a familiar IP or region alone must not establish ownership. Correlate risky new sessions, mass session revocation and replacement of security factors before allowing irreversible ownership changes. This is a product-security suggestion, not a claim that a particular server-side vulnerability or attack sequence has been established. Private incident evidence has been sent through Telegram's security and support channels.

🏖 Wonchoe 🏝

Full scenario for Telegram engineering/security to VERIFY, not a proven timeline:
1. Phishing obtains a session.
2. After ~24 hours the attacker terminates the owner's other sessions, keeping their own. Telegram documents a 24-hour restriction for fresh sessions; timing here is unverified.
3. Repeated login-code/recovery requests allegedly exhaust quotas, preventing owner reentry despite SIM control.
4. After ~another 24 hours, the attacker allegedly changes email/security factors and the account phone number. This second interval and these changes are unverified. Login email, 2FA recovery email and phone changes are distinct; email alone does not detach a number.
5. Possible bulk downloading of cloud chat history/media, potentially for resale. Neither full-history extraction nor resale is established; this does not imply new-session access to Secret Chats or proven permanent account loss.

My father lost all known sessions while retaining the SIM; a login attempt returned FLOOD_WAIT_78009. Static phishing-code inspection found authorization calls and transmission of phone/login-response data and page localStorage. This does NOT prove who caused the limit or the full sequence.

Please correlate session origins/revocations, actual auth methods, quota exhaustion/extensions, factor changes and unusual history retrieval. Private account details/evidence were sent to Security and Support; please escalate to engineering.

Protect a bounded recovery allowance using strong prior-device/factor evidence from exhaustion by unrelated requests. Historical IP/region should inform risk, not prove ownership; IP-only limits allow rotation. Correlate risky sessions, mass revocations and bulk reads; challenge/limit the suspicious session, not automatically the victim's entire account. Preserve legitimate export/sync and provide clear retry guidance and non-destructive recovery.

Update, 22 September 2026: the recovery flow has now demonstrated the exact trap we were concerned about.

My father retains control of his SIM but has no accessible Telegram sessions after the account takeover. After the previous FLOOD_WAIT elapsed, the web login advanced to a code-entry screen explicitly saying: "We have sent you a message in Telegram with the code." It did NOT say SMS. No SMS fallback was visible on that screen. Access was not restored. A subsequent attempt returned FLOOD_WAIT_86263: another 23 hours, 57 minutes and 43 seconds.

What is the recovery logic here? The legitimate owner controls the phone number, yet the code is routed into the very account he is trying to recover, potentially to an attacker-controlled session. An authenticated session is not proof that its current operator is still the rightful owner. Making recovery depend on access to the compromised account is an unacceptable recovery dead end.

We cannot verify which sessions received the code or who caused the new rate limit; owner-side retries also occurred, so please establish causation from server logs rather than assumptions. The confirmed UI sequence is: wait expires -> code sent via Telegram, not SMS -> no restored access; a later attempt encounters another nearly day-long wait.

Please escalate this to authentication/security engineering. Explain why this delivery route was chosen, provide a clearly discoverable, protected alternative when all trusted sessions are lost, and investigate whether unrelated requests can exhaust the owner's recovery allowance. Keep SIM-swap and brute-force protections; we are asking for secure, non-destructive recovery, not an unconditional SMS bypass. Private account details were already sent to Security and Support.

Screenshot attached: the affected account's web login says the code was sent in Telegram, with no SMS option visible on the captured screen. Only the middle phone-number digits have been covered with an opaque rectangle; the remaining pixels are unchanged.

Important clarification: I then tested the mobile app with MY OWN, different phone number. It also initially offered a Telegram code, but displayed an option below to send via SMS. This does not establish whether SMS will be offered for my father's compromised account. His next attempt must wait for the new FLOOD_WAIT to expire.

Who designed and approved this recovery logic? How is a legitimate owner, still holding the SIM but locked out of all trusted sessions, supposed to recover when the web flow sends the code into the compromised account and shows no usable alternative? Why is the mobile SMS route not clearly explained or linked from that web screen? This is an unacceptable recovery experience, not merely a confusing label.

Please investigate the web/mobile difference and provide a clear, secure route for users who have lost all trusted sessions, with abuse and SIM-swap protections. We cannot prove who received the Telegram code or who caused the renewed rate limit; please correlate the private incident details with server logs.