For more than a year now I have been using Telegram Messenger: it is convenient and, as far as I thought, completely confidential. Since I am a web application security researcher, I had to check the appropriate version of the application for vulnerabilities. I did not see an urgent need for this because of the reputation of the messenger as “the most protected”. I thought I was wasting my time and won’t find anything. But recently, testing one site that interacted with the domain, I had a chance to doubt the security of Telegram, and the determination to test it for vulnerabilities quickly increased.

It all started with the fact that I checked the site of my crypto club for vulnerabilities, where I had previously purchased a subscription to recommendations for buying cryptocurrency.

Registration on the site is available only through referral (invitation) links, and there is also a section for sending a message to the curator After testing, there was neither csrf, nor xss, nor any other vulnerability. But special attention was drawn to the section with messages, where correspondence with my curator was presented. I decided to check this url for iDOR vulnerability by increasing the id by one position, and the vulnerability was confirmed - I saw the personal data of another user. Since the site did not have a function for sending messages to other users, we can talk with accuracy about iDOR + Disclosure Information.


Moving on - we buy the product, after its successful purchase there is a redirect to this url 20boughtproduct , while the text can be edited - mostly the characters are filtered , but there is a place where the text gets in and there is no filtering. We write this payload

< iframe/onload=alert(document.domain)> and send PoC to resource owners. Also there was a hint of Server Side Include, but exec cmd is disabled, with this payload --#exec cmd="ls" --> (swal(' ', '"-->\'-->`-->[an error occurred while processing the directive](none).

Also, I noticed a page with the goods, there was a blind sql injection. As evidence of the danger I was asked to provide the names of the database and tables. Hands to exploit blind sql injection would be very long, so the sqlmap program came to the help:


After these three vulnerabilities, CSRF was discovered in changing personal data, which led to account takeover by email recovery, Stored XSS, as well as a minor bug that allowed to buy goods for a price two times less than its announced cost. The main danger of all these vulnerabilities (not counting sql injection), in my opinion, was sending to collected email-addresses, links to xss in a bunch with csrf and widthdraw referral charges on the attacker’s details. Then that vulnerability was found that made me doubt the security of telegram for the web.

Usually, in the settings section there is a button for connecting a bot, with which you can get recommendations for cryptocurrency trading. The button is linked to such a url

Having the habit of constantly checking sensitive data in a url for search engine placement (for example, I found google dork in twitter or in exchanges), this time I checked I wrote this dork: inurl: Another_bot start=? . I received one code, and having successfully logged into the bot, I began to receive insights worth $500, I was able to see the name of partners and the account balance.


Judging by the fact that the code for the telegram bot appeared in a search engine, has obvious problems with the confidential content indexing. This is due to the fact that search engines are allowed. And they are allowed because there are no restrictions in the robots file. When you try to view url, it is redirected to the user's page, this is mean that this file does not exist.

Due to the lack of robots file looms out Disclosure Information vulnerability. Craft dorks in order to show the danger of vulnerability:

1) Some users use email as a name or username. All this information gets into the search engine, whether users want it or not It reveals 11600 gmail addresses, 1500 yahoo, as well as, gmail and But such disclosure is a controversial proof of the danger, because it is public information.

2) 5 000 000 links are opened for access to private chat rooms and channels. Moreover, every day this figure is growing, because there is no robots.txt.


The first problem, in my opinion, is that links to private chat rooms / channels will remain in search engines forever, they can not be deleted. But many people trust Telegram for a long time without changing the links for access. And maybe they will never change, thinking that their correspondence is completely confidential. But this is not so: now any person can read the correspondence of employees, the security official can learn about the terrorists messages, and your girlfriend will find out that neighbor Amanda is not just "an old friend from childhood." Only the fact of draining such a large number of links for chat access "reduces the concept of private chat to nothing."

The second, no less exciting problem is that developers are absolutely “carefree” about this vulnerability, and the number of links is increasing every day. If during my report (January 7) Google had 900,000 such links, then now them 5 000 000! I agree that among all these links there are “clickbate” telegram channels that in advertisements use the links************** to “fill" the number of subscribers, but also there are a lot of private chats and other private channels. Until now, the developers have not added robots.txt to (more than three months have passed since my report), and, I think, they will never add it. If there would be a desire, they would add at once, it’s not at all difficult - just upload a txt file to the site index.

Looking through the dorks, I found such an interesting url The interesting thing here is that this is not a link to a channel / person, but a redirect to the ISIS site (most likely), and only this site uses /iv? from 2015 to today. The contacts also contain the link

We substitute another site in url= for testing, everything worked - this is the second vulnerability in Telegram - Open Redirect, and this url can be used as a proof of concept, Open Bug Bounty confirmed vulnerability exist and fix. Vulnerability allows to make a redirect from to any phishing site, download a trojan, malicious js (for example, js miner or use the last 0-day in intel processors), etc.

After that, I moved to the article creation service from Telegram - There is no way to edit someone else’s records, there are only one subdomain, the directories bruteforce don't give any result. I created a test article and tried to edit it - in response to this action, this request is sent POST /save HTTP / 1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Accept: application/json, text/javascript, /; q=0.01
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Content-Type: multipart/form-data; boundary=—————————TelegraPhBoundary21
Content-Length: 1273
Cookie: tph_uuid=80SI6VtGetOhKd5LaFjBRtK7I6EsdW0lWS21LvFZWt
Connection: close
Content-Disposition: form-data; name=»Data»;filename=»content.html»
Content-type: plain/text
Content-Disposition: form-data; name=»title»
Content-Disposition: form-data; name=»author»

Content-Disposition: form-data; name=»author_url»

Content-Disposition: form-data; name=»page_id»
Судя по этому запросу, для того, чтобы отредактировать статью на telegraph, нужен только номер страницы page_id и чтобы автор статьи перешёл по ссылке нашего эксплойта. То есть никакой защиты, например csrf токенов, здесь попросту нет.

Third vulnerability — CSRF. I found out that the token is in the source of the article, for example, the article belongs to id 7f0d501375c9e2acbd1ef:
Since the article can still be edited for a very long time, we can just find out the page id, make an automatic exploit and successfully change the record.

PoC video
Using creates a large number of articles, so this vulnerability will be very valuable for attackers, as it allows you to change, for example:

  • — статью с важной новостью;
  • — article with crypto wallet update (or any other website);
  • - an article where is a ref. links to some services in description, replacing them with your own ref link, - on this, by the way, you can earn a lot of money - in my article I talked about how a certain investor made $300,000 on publishing his ref. the links, and since his contacts are known to everyone, it would have been possible to send the exploit to him, to replace the ref link, and this action would have been imperceptible.

I sent these vulnerabilities to, as stated in their message about BugBounty, also, there is a mention of telegram bug bounty on platform BugCrowd.


For a long time I did not receive a response. Then I wrote to Pavel Durov (it was stupid desicion, I agree, because his account, besides me, is written by a lot of people, and he does not read private messages), and also asked my friends to share the developers' contacts. I sent a message to the developer, but he didn’t care about the vulnerability, he just read and ignored the letter. Then I sent a letter to He handed over to check the box and take my vulnerabilities. Within 9 days after the report I got answer.

On the first vulnerability, I received this response:

“Everything that is displayed on pages - username, bio, posts from public channels - is public information”

At the same time, the developer declined to respond to the message about the disclosure of private links. After I showed private access links a second time, they said that they would fix the vulnerability and pay € 50. But, as already mentioned, even after 3.5 months there is no correction. On the contrary, the situation has worsened.

As you understand, the reward of € 50 for such a vulnerability is scanty and, one might even say, unfair. But this is Bug Bounty, and they decide how much to pay. I did not discuss further and just agreed with the amount. But for the last vulnerability, I received a fairly generous reward, and, precisely because of these "swing", it is difficult to draw any conclusion about this Bug Bounty, unlike, for example.

As a result, I received such awards for the sent vulnerabilities:

Search for vulnerabilities on the crypto club website

  1. Blind Sql Injection - $ 4000.
  2. Vulnerability, revealing codes to the bot - $ 1000.
  3. Everything else is $ 1500.


  1. Disclosure Information — €50.
  2. Open Redirect — €100.
  3. CSRF — €1400 ($1750).

Conclusion from the article:

  • Always add robots.txt to your website with rules that prohibit indexing of sensitive content. It can be email, login, phone, link with receipt, link for autologin, etc.
  • If you have created a private chat and add someone you need, and do not disclosure the link, because the link for access will sooner or later become public and can be seen in a search engine.

UPD: Link disclosure vulnerability no longer works. Open Redirect and CSRF have been fixed.

P.S: To keep abreast of my latest articles, I recommend to subscribe to twitter, link is above.
Previous article: How I hacked companies related to the crypto currency and earned $60,000

ru_RURussian en_USEnglish