An ‘Easter Egg’ in Telegram. How to log in without cloud passwords and notifications

Root of the problem

The exploitation scenario is simple: you open the built-in Telegram browser and follow a link to web.telegram.org. You get authenticated almost instantly — without entering a password, without confirming your login, without notifications… And this seems to be logical since you are already in Telegram. But now imagine that an attacker manages to intercept this token. And uses it… let’s say, in another browser. Or on another device…

What happens: Telegram starts a session with broad privileges — without requiring a cloud password, without notifying the user, and without checking where this session is used. No browser binding. No logs. No restrictions!

Real-life case: cryptocurrency theft

I am involved in IT education in the framework of CakesCats, an independent nonprofit project focused on digital hygiene, security, and analysis of modern threats. People address CakesCats with their questions and cases.

The victim of this incident contacted me via public channels in early 2025. He lost a significant amount of money in cryptocurrency as a result of a theft.

I performed the basic audit and was truly impressed by the virtual absence of traces. Such mysterious crimes occur extremely rarely, and it was the first such case in my life. But I decided not to give up and eventually discovered a 0-day in Telegram.

Below is the reconstructed chain of events:

• The user opened a website and logged in with Telegram Login Widget;
• A few hours later, all funds disappeared from victim’s crypto wallets;
• Seed phrases were stored in Telegram (a very bad practice, by the way);
• Using the session, the attacker retrieved the contents of victim’s notes without explicitly logging into Telegram and gained access to cryptocurrency; and 
• There were no notifications about unusual new sessions or login confirmations: Telegram (or the victim’s device) ‘didn’t notice’ the theft.

Technical context

The victim used an iPhone with iOS version 18.3 and the Safari browser. Also, he logged into Telegram using a widget from the Telegram Widgets series.

I thoroughly checked all client devices for traces and interviewed the victim: he neither found a ‘lost flash drive’ nor did he notice anything suspicious. The situation was absolutely abnormal: I cannot remember a case without a single piece of real evidence. Usually, the situation is much simpler: someone’s carelessness, or malicious intent of someone from a close circle, or malware… But not in this case.

An attack on macOS or iOS requires significant effort: it’s a complex operation that inevitably leaves traces: nonstandard requests, access rights failures, or even a series of crashes in the logs on the day when pivoting was performed. But there was nothing like that in the case under investigation.

At the time of the theft, an IT conference involving telecom and cybersecurity structures was held in the region where my client was located. The owner of the iPhone stayed at a hotel that hosted participants of this conference (his trip was spontaneous). This could be a coincidence, but could also indicate a highly organized attack at the APT level. Such attacks often involve IMSI-catchers or similar equipment, as well as nonpublic exploits.

Only one interesting detail was discovered: the iPhone baseband logs lacked records for two days when the attack was presumably performed. This was the only ‘blind’ spot over the period of 2.5 months.

Needless to say, rooting an iPhone isn’t a trivial task — even if this is your own phone. And in the case under investigation, some unknown people delivered such an attack remotely and retrieved only the contents of notes in Telegram! The client also had brokerage and banking applications, and funds were stored there as well. But none of these applications were affected.

Using the exclusion method and step-by-step analysis of the killchain attack, I was able to formulate the only plausible hypothesis: a Telegram session was somehow hijacked. Where and how this happened still remains a mystery. None of the standard scenarios could be confirmed. And this version prompted me to delve deeper into possible manipulations with Telegram sessions.

But there is one but…

Telegram Login Widget and invisible sessions

An interesting behavior was recorded during testing.

• Under normal conditions, when you log in with Telegram Login Widget, a new device and its ‘session’ appear: it can be seen in account settings;
• However, especially if you are logging in via Telegram sites, a new session isn’t created each time you log in. You won’t see it: nether in the list of devices nor in the list of connected sites. Furthermore, even if you manually log out of your account, the authorization token will remain valid, thus, enabling you to log in again and again without restrictions; and 
• The only trace is a system notification from Telegram about the recent login to your account. And then silence… However, if you subsequently reauthorize on third-party services using the same token, everything will work fine, which confirms that your session is still active.

Such behavior makes it difficult to track or even detect that someone has logged into a user account. Session management becomes impossible.

Hypothesis: widget → token → access to data

In practice, a widget-based login mechanism should look as follows:

1. The user clicks on the Telegram Login button on the website;
2. Telegram returns a session token that is available inside the browser;
3. This token can be intercepted prior to the redirect. For example, this can be done using JS logging, an extension, certain malware, or traffic sniffing; and 
4. After receiving the token, the attacker can authorize inside the Telegram infrastructure (e.g. on web.telegram.org in another browser) and gain access to the account or some parts of it (e.g. bookmarks or chats) without raising any suspicions.

Importantly:

• Telegram doesn’t always add such a session to the log;
• cloud password (2FA) isn’t requested; and 
• the token can be reused if this operation is performed quickly enough or from the same IP.

There are plenty of strange circumstances in the case under investigation, including:

• no notifications (i.e. the user is unaware of unauthorized access);
• bookmarks in Telegram aren’t encrypted (or are available within the session);
• basic iOS logs have ‘disappeared’ at the very moment of the attack;
• Telegram Login Widget issued a token with private chat and call privileges; and 
• a possible data theft vector involves the built-in Telegram browser where a token can be intercepted prior to the redirect.

In real life, this looks as follows. When a user logs in via Telegram Browser (the one used for auto-login to such services as bugs.telegram.org or web.telegram.org), a token is created. Importantly:

• cloud password isn’t required even if it’s enabled;
• no new sessions are created in the “Active devices” list;
• no Telegram login notifications are triggered;
• the token isn’t bound to the browser or device from where it was received; and 
• the token is (in fact, was) able to accept incoming sessions and start private ones.

This is almost an ideal scenario for session hijacking.

Proof-of-Concept: a token from nowhere

Technically, everything is simple. You use the built-in Telegram browser (e.g. when following a link inside Telegram since it’s enabled by default), snatch the moment right before the redirect, and save the authorization token.

If you do this quickly enough, you can use this token anywhere: in Firefox, in Chrome, and even in headless scenarios. Most importantly, all these operations can be performed without the need to log in, confirm the login attempt, or reauthorize.

How did it work in the case under investigation? Imagine that a user has Telegram active; there is an open session somewhere in the background; and the user clicks on a link to web.telegram.org. While the Telegram browser makes a redirect, the attacker intercepts the token (either by installing a plugin, or making JS injections, or using an exploit on the client side, or even by viewing the browser history). And that’s it!

After that, everything is simple: the token is inserted into an URL, and the attacker gets a Telegram Web session: a fully-functional, workable, and untraceable session. Without a password. Without 2FA…

Why is it working?

The main problem is the lack of strict token binding to the environment. Telegram generates tokens that act as entry tickets to the ‘full version’, but doesn’t control who uses them, where, and how. This is a classical design error: authorization token without an execution environment context.

Even if Telegram believes that tokens are bound to a certain session, in reality:

• they live longer than they should;
• they aren’t invalidated (!) when the session is deleted; and 
• they can be used outside the browser where they were created.

Recent fixes in Telegram

At the time of writing, it was clear that Telegram developers have edited the behavior of widgets: now they mostly create sessions without privileges. However, there were no public notifications about this. No mentions in Telegram Dev channels, no entries in the changelog, nothing…

It’s still unknown whether this vulnerability was fixed as a result of an internal audit, user complaints, or an external report. But the fact remains: it existed, and its exploitation was possible — quietly, without a trace, and with real access.

I would also like to note some changes in Telegram Widgets: on the day when I was writing this text, the developers attempted to restrict the behavior of widgets. Apparently, widgets don’t create sessions with privileges anymore. But this doesn’t apply to automatic authorization tokens generated by the system when you follow a link in the Telegram browser. Such tokens can be used to bypass all restrictions. All of them!

Conclusions

Telegram authorization tokens can be used to access victim’s account bypassing the cloud password and notification systems. A session created using the built-in Telegram browser can potentially be intercepted and reproduced by an attacker. The lack of full control over the environment (i.e. such parameters as User-Agent, IP address, or digital fingerprint of the device) makes Telegram vulnerable to classical session hijacking attacks.

And this is not just a technical bug, but an architectural vulnerability that requires the most serious attention from both the developers and community.

Such an ‘Easter’ (since I discovered it at Easter) 0-day! A nice surprise for a researcher, but definitely not for users. If you have Telegram with two-factor authentication enabled and believe that no one can log in without your knowledge — think twice! Especially if you have something to lose (as in the case of my client).

Beware and be vigilant!