Wprowadzenie do problemu / definicja
W Telegram Desktop wykryto podatność typu stored XSS oraz HTML injection, która dotyczyła funkcji eksportu rozmów do formatu HTML. Problem wynikał z nieprawidłowego osadzania treści przycisków botów typu inline keyboard w wygenerowanych plikach, co umożliwiało zapisanie złośliwego kodu JavaScript w historii czatu i jego późniejsze uruchomienie po otwarciu eksportu w przeglądarce.
To istotny przypadek, ponieważ zagrożenie nie aktywowało się w samym komunikatorze, lecz dopiero na etapie pracy z lokalnym archiwum. W praktyce oznacza to, że użytkownik mógł uznać wyeksportowany plik za bezpieczną kopię rozmowy, podczas gdy zawierał on aktywny ładunek zdolny do kradzieży danych lub manipulacji treścią.
W skrócie
- Podatność dotyczyła Telegram Desktop dla Windows, macOS i Linuksa.
- Wektor ataku opierał się na wiadomościach botów z przyciskami inline, których tekst nie był poprawnie escapowany podczas eksportu do HTML.
- Po otwarciu podatnego eksportu skrypt mógł odczytać treść wiadomości, metadane oraz informacje o czacie.
- Zebrane dane mogły zostać przesłane na serwer kontrolowany przez atakującego.
- Problem został usunięty w nowszych wersjach klienta, ale starsze eksporty HTML mogą nadal być niebezpieczne.
Kontekst / historia
Opisany problem był skutkiem braku odpowiedniego filtrowania jednego z pól używanych przy generowaniu eksportów HTML. Według ujawnionych informacji podatna logika występowała w stabilnych wydaniach od wersji 4.15.1, udostępnionej w marcu 2024 roku. Poprawka została przygotowana pod koniec czerwca 2026 roku, następnie trafiła do kanału beta 3 lipca 2026 roku, a później do stabilnego wydania 7.0.1 opublikowanego 14 lipca 2026 roku.
Na uwagę zasługuje odroczony charakter tego wektora ataku. Złośliwa wiadomość mogła przez długi czas pozostawać w historii rozmowy bez żadnych widocznych oznak nadużycia. Dopiero eksport czatu do HTML i otwarcie pliku w przeglądarce prowadziły do wykonania osadzonego skryptu, co znacząco utrudnia wykrycie incydentu oraz ocenę momentu kompromitacji danych.
Analiza techniczna
Źródłem podatności było nieescapowanie tekstu przycisków inline keyboard podczas budowania dokumentu HTML. W efekcie znaki specjalne i znaczniki HTML mogły zostać zapisane jako aktywny kod, a nie jako zwykły tekst. Jeżeli bot dostarczał odpowiednio spreparowaną etykietę przycisku, przeglądarka interpretowała ją po otwarciu eksportu jako wykonywalny JavaScript.
Z perspektywy technicznej był to klasyczny stored XSS osadzony w artefakcie eksportowym. Ładunek działał w kontekście lokalnego pliku HTML, a nie w obrębie samej aplikacji Telegram Desktop. Taki skrypt mógł odczytać zawartość wiadomości zapisanych w konkretnym pliku, zebrać nazwy nadawców, daty, znaczniki czasu oraz metadane związane z czatem, a następnie przesłać te informacje na zewnętrzny serwer.
Badacze wskazali również na możliwość naruszenia integralności prezentowanych danych. Złośliwy kod mógł modyfikować widok eksportu i wyświetlać użytkownikowi fałszywe treści, na przykład formularze lub spreparowane fragmenty konwersacji. Taki scenariusz zwiększa ryzyko socjotechniki, utrudnia analizę incydentów i podważa wiarygodność lokalnych archiwów wykorzystywanych jako materiał referencyjny.
Warto dodać, że eksporty HTML w Telegram Desktop mogą być dzielone na kilka plików obejmujących określone partie wiadomości. Ogranicza to zasięg pojedynczego wykonania skryptu do konkretnego pliku, ale nie eliminuje zagrożenia. W środowiskach biznesowych nawet częściowy wyciek danych z jednego archiwum może mieć wymierne skutki operacyjne, prawne lub wizerunkowe.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności jest utrata poufności danych zawartych w wyeksportowanych rozmowach. Dotyczy to zarówno samych wiadomości, jak i metadanych, które mogą ujawniać strukturę kontaktów, harmonogram komunikacji oraz charakter relacji pomiędzy uczestnikami rozmowy. Dla organizacji oznacza to ryzyko wycieku informacji projektowych, operacyjnych i personalnych.
Drugim obszarem zagrożeń jest naruszenie integralności. Jeśli eksport HTML jest wykorzystywany jako materiał audytowy, archiwum dowodowe lub źródło analizy powłamaniowej, możliwość dynamicznej podmiany wyświetlanej treści może prowadzić do błędnych ustaleń. Nawet bez trwałej modyfikacji pliku atakujący może wpłynąć na to, co widzi użytkownik w momencie otwarcia dokumentu.
Istotne jest także długotrwałe oddziaływanie problemu. Aktualizacja klienta usuwa podatność z procesu tworzenia nowych eksportów, ale nie neutralizuje zagrożenia obecnego w archiwach wygenerowanych wcześniej. Oznacza to konieczność traktowania historycznych plików HTML jako nieufnych do czasu ich ponownego wygenerowania lub bezpiecznego odizolowania.
Rekomendacje
Podstawowym krokiem powinno być zaktualizowanie Telegram Desktop do wersji zawierającej poprawkę. To jednak nie rozwiązuje problemu wcześniej utworzonych eksportów, dlatego potrzebne są również działania organizacyjne i techniczne związane z istniejącymi archiwami.
- Zidentyfikować wszystkie eksporty HTML utworzone przed wdrożeniem poprawionej wersji klienta.
- Traktować stare pliki jako potencjalnie złośliwe lub skażone.
- Ponownie wygenerować eksporty z użyciem aktualnej wersji aplikacji.
- Nie otwierać starych archiwów HTML w standardowej przeglądarce z aktywną obsługą JavaScript.
- Jeśli analiza starego eksportu jest konieczna, przeprowadzać ją w środowisku izolowanym.
- Rozważyć stosowanie mechanizmów blokujących aktywną zawartość w lokalnych plikach HTML.
- Uwzględnić eksporty danych z komunikatorów jako osobną powierzchnię ataku w procedurach bezpieczeństwa.
- Zweryfikować wykorzystanie botów oraz treści publikowanych dalej do grup i kanałów.
Z punktu widzenia zespołów SOC, IR i DFIR warto również przeanalizować, czy organizacja nie przechowuje eksportów HTML jako materiału dowodowego bez dodatkowej normalizacji do formatu nieaktywnego. Bezpieczniejszym podejściem może być archiwizacja danych w formie, która nie pozwala na wykonanie kodu po stronie klienta.
Podsumowanie
Luka w Telegram Desktop pokazuje, że realne ryzyko bezpieczeństwa może pojawić się nie tylko podczas korzystania z komunikatora, ale także na etapie eksportu i późniejszego przeglądania danych. Błąd związany z nieprawidłowym escapowaniem tekstu przycisków inline umożliwiał osadzanie złośliwego JavaScript w archiwach HTML, co prowadziło do ryzyka eksfiltracji wiadomości, metadanych i manipulacji treścią.
Najważniejsze działania obronne obejmują aktualizację klienta, identyfikację oraz ponowne wygenerowanie starych eksportów, a także traktowanie historycznych plików HTML jako nieufnych. Dla organizacji to dodatkowe przypomnienie, że nawet pozornie bierne archiwa mogą stanowić aktywną powierzchnię ataku.