Luka w Telegramie na Androidzie mogła umożliwić przejęcie urządzenia po odebraniu połączenia - Security Bez Tabu

Luka w Telegramie na Androidzie mogła umożliwić przejęcie urządzenia po odebraniu połączenia

Cybersecurity news

Wprowadzenie do problemu / definicja

Podatności w komunikatorach obsługujących połączenia głosowe należą do najpoważniejszych kategorii błędów w aplikacjach mobilnych. Wynika to z faktu, że mogą zostać uruchomione już na etapie zestawiania połączenia, a użytkownik często nie musi wykonywać żadnych dodatkowych działań poza samym odebraniem rozmowy. W opisywanym przypadku problem dotyczył Telegrama dla Androida i mechanizmu przetwarzania komunikatów związanych ze stanem mediów podczas połączeń.

Błąd nie oznaczał prostego, samodzielnego zdalnego wykonania kodu w każdym scenariuszu, ale mógł stanowić kluczowy element większego łańcucha ataku prowadzącego do przejęcia urządzenia. To właśnie takie podatności są szczególnie cenione przez zaawansowanych napastników, którzy łączą kilka słabości w jeden skuteczny exploit chain.

W skrócie

  • Podatność dotyczyła Telegrama dla Androida w wersjach od 8.6.2 do 12.10.3.
  • Problem został usunięty w wersji 12.10.4.
  • Atakujący potrzebował zwykłego konta Telegram.
  • Warunkiem powodzenia ataku było odebranie połączenia głosowego przez ofiarę.
  • Skuteczne wykorzystanie wymagało połączenia błędu z dodatkowymi lukami.
  • Nie ma publicznie potwierdzonych informacji o aktywnym wykorzystywaniu tej podatności.

Kontekst / historia

Informacje o luce ujawniono pod koniec października 2026 roku. Z dostępnych ustaleń wynika, że problem obejmował szeroki zakres wydań Telegrama dla Androida publikowanych od marca 2022 do września 2026 roku. To oznacza, że potencjalna powierzchnia ataku była istotna, zwłaszcza w środowiskach, gdzie użytkownicy opóźniają aktualizacje aplikacji mobilnych.

Istotnym elementem tła tej sprawy jest to, że poprawka została wdrożona jeszcze przed szerokim nagłośnieniem problemu. Jednocześnie brak identyfikatora CVE oraz rozbieżności w ocenie praktycznej wykorzystywalności luki pokazują typowe napięcie między badaczami a producentami oprogramowania. Z perspektywy dostawcy usterka może wydawać się ograniczona, natomiast badacze często oceniają ją w szerszym kontekście realistycznych łańcuchów ataku.

Sprawa zwraca również uwagę na ryzyka związane z kodem współdzielonym między platformami. Jeżeli biblioteka odpowiedzialna za obsługę połączeń jest używana szerzej, nawet jednostkowy błąd na jednej platformie powinien prowadzić do dokładnego przeglądu całego komponentu.

Analiza techniczna

Techniczna przyczyna problemu miała dotyczyć nieprawidłowej obsługi komunikatu typu MediaState wykorzystywanego podczas zestawiania i utrzymywania połączenia. Tego rodzaju komunikaty odpowiadają za przekazywanie informacji o stanie mikrofonu, kamery czy orientacji obrazu. W analizowanym przypadku aplikacja miała błędnie odczytywać pola struktury danych, sprawdzając jedną wartość, a następnie odwołując się do innego pola nawet wtedy, gdy nie zostało ono poprawnie dostarczone.

Taki wzorzec jest typowy dla błędów naruszających bezpieczeństwo pamięci. Jeżeli parser nie waliduje prawidłowo kompletności i spójności danych wejściowych, może dojść do użycia nieprawidłowego stanu, odczytu niezainicjalizowanych danych albo przekazania błędnych informacji do dalszych komponentów aplikacji. W praktyce taki defekt może stać się punktem wyjścia do bardziej zaawansowanego scenariusza ataku.

Według opisu badaczy sama luka miała być tylko jednym z etapów. Połączenie jej z dodatkową podatnością umożliwiającą wyciek informacji mogło pozwolić na wyjście poza kontekst aplikacji Telegram. Następnie pełne przejęcie urządzenia wymagało jeszcze trzeciego elementu, czyli luki lokalnej lub systemowej prowadzącej do eskalacji uprawnień. Oznacza to, że nie był to klasyczny przypadek samowystarczalnego RCE, lecz ważny komponent złożonego łańcucha kompromitacji.

Z punktu widzenia obrony nie obniża to jednak znaczenia problemu. Współczesne operacje ofensywne regularnie korzystają z kilku umiarkowanych podatności, które dopiero po połączeniu stają się krytyczne. Szczególnie niebezpieczne są te błędy, które można aktywować przez funkcje komunikacyjne, bez konieczności otwierania pliku lub klikania odnośnika.

W dostępnych analizach wskazano również, że podatność potwierdzono na urządzeniach ARM64 oraz w połączeniach prywatnych. Nie wykazano jednoznacznie analogicznego wpływu na iOS, aplikację desktopową ani połączenia grupowe, ale wspólna logika połączeń powinna skłonić do dodatkowej weryfikacji kodu również poza Androidem.

Konsekwencje / ryzyko

Gdyby atakującemu udało się skutecznie domknąć pełny łańcuch exploita, konsekwencje mogłyby być bardzo poważne. Potencjalny dostęp do urządzenia otwiera drogę do przejęcia wiadomości, podsłuchu z użyciem mikrofonu, dostępu do kamery, kradzieży tokenów sesyjnych czy przechwycenia kodów wieloskładnikowego uwierzytelniania. W środowisku firmowym mogłoby to dodatkowo prowadzić do kompromitacji aplikacji korporacyjnych i dalszego ruchu bocznego.

Ryzyko zwiększa atrakcyjny wektor wejścia. Połączenia głosowe w komunikatorach są postrzegane jako naturalna i zaufana funkcja, dlatego użytkownicy rzadziej traktują je jako potencjalny nośnik ataku. Dodatkowo konieczność jedynie odebrania połączenia oznacza niski próg interakcji po stronie ofiary.

Z drugiej strony należy zachować właściwe proporcje. Brak publicznie potwierdzonych przypadków aktywnego wykorzystania oznacza, że nie ma obecnie dowodów na szeroką kampanię nadużyć. Nie zmienia to jednak faktu, że każda luka związana z mechanizmem połączeń VoIP powinna być traktowana priorytetowo, szczególnie w organizacjach dopuszczających model BYOD oraz korzystających z komunikatorów do wymiany informacji służbowych.

Rekomendacje

Najważniejszym krokiem jest aktualizacja Telegrama dla Androida do wersji 12.10.4 lub nowszej. W przypadku środowisk firmowych warto zweryfikować poziom aktualizacji aplikacji z użyciem narzędzi MDM, EMM lub innych mechanizmów zarządzania flotą urządzeń mobilnych.

  • Ograniczyć możliwość odbierania połączeń od nieznanych użytkowników.
  • Skonfigurować ustawienia prywatności połączeń zgodnie z modelem zagrożeń organizacji.
  • Monitorować urządzenia pod kątem nietypowych awarii, restartów interfejsu i oznak eskalacji uprawnień.
  • Egzekwować szybki patch management również dla aplikacji mobilnych, a nie tylko systemu operacyjnego.
  • Prowadzić inwentaryzację komunikatorów używanych w organizacji i oceniać ich ekspozycję na połączenia przychodzące.
  • Rozważyć wdrożenie rozwiązań mobile threat defense lub EDR dla urządzeń mobilnych o podwyższonym profilu ryzyka.

Z perspektywy zespołów bezpieczeństwa istotne jest także modelowanie zagrożeń wokół funkcji VoIP i RTC. Biblioteki odpowiedzialne za połączenia, media, parsery komunikatów i komponenty natywne powinny być objęte pogłębionym testowaniem, w tym fuzzingiem oraz analizą bezpieczeństwa pamięci.

Podsumowanie

Luka w Telegramie dla Androida pokazuje, że pozornie ograniczony błąd w obsłudze połączeń może stać się ważnym elementem krytycznego łańcucha ataku. Choć scenariusz wymagał połączenia kilku podatności, sam fakt możliwości uruchomienia ścieżki kompromitacji po odebraniu połączenia głosowego znacząco podnosi wagę problemu.

Dla użytkowników indywidualnych i organizacji kluczowe pozostają szybkie aktualizacje, świadome zarządzanie prywatnością połączeń oraz traktowanie bezpieczeństwa aplikacji mobilnych jako pełnoprawnej części strategii cyberbezpieczeństwa.

Źródła

  1. Telegram Android Flaw Lets Attackers Run Code When Users Answer Voice Calls — https://thehackernews.com/2026/10/telegram-android-flaw-lets-attackers.html
  2. Telegram for Android Source Code (version 12.10.3) — https://github.com/DrKLO/Telegram
  3. tgcalls commit: Fix camera rotation — https://github.com/TelegramMessenger/tgcalls
  4. Zero Day Initiative Advisory on rlottie / CVE-2026-111105 — https://www.zerodayinitiative.com/
  5. OffensiveCon abstract on Telegram/rlottie research — https://www.offensivecon.jp/