Badacze znaleźli dwa praktyczne sposoby wstrzykiwania fałszywych wiadomości do Signala — jeden z błędów w Sealed Sender pozwalał złośliwemu serwerowi ingerować także w czaty grupowe bez ostrzeżenia użytkownika

Signal szyfruje treść rozmów end-to-end, ale badacze pokazali coś bardziej niewygodnego niż klasyczne „złamanie szyfrowania”: złośliwy lub przejęty serwer mógł doprowadzić do pojawienia się w aplikacji wiadomości, której prawdziwy rozmówca wcale nie wysłał. W jednym wariancie użytkownik dostawał ostrzeżenie dotyczące numeru bezpieczeństwa. W drugim — związanym z Sealed Sender — na Androidzie fałszywa wiadomość mogła trafić także do czatu grupowego bez widocznego alarmu i bez szczególnych warunków wstępnych.

Ataki opisali Kien Tuong Truong z ETH Zurich, Noemi Terzo z Max Planck Institute for Security and Privacy oraz Kenneth G. Paterson z ETH Zurich w pracy Message Injection Attacks Against Signal, zaprezentowanej w ramach USENIX Security 2026. To istotne rozróżnienie: badacze nie twierdzili, że ktoś masowo czytał zaszyfrowane rozmowy Signala albo złamał podstawowe prymitywy kryptograficzne. Problem dotyczył integralności i uwierzytelniania wiadomości — czyli odpowiedzi na pytanie, czy komunikat wyświetlany jako pochodzący od konkretnej osoby rzeczywiście został przez nią wysłany.

Oba błędy zostały zgłoszone Signalowi i poprawione jeszcze przed szeroką publikacją wyników. Mimo to przypadek jest ważny, bo pokazuje ograniczenie, o którym użytkownicy bezpiecznych komunikatorów rzadko myślą: poprawna kryptografia nie wystarcza, jeśli informacje o tożsamości są niewłaściwie przenoszone między warstwami aplikacji.

Pierwszy atak wykorzystywał rozjazd między tożsamością opartą na numerze telefonu i nazwie użytkownika

Pierwszy scenariusz dotyczył klientów Signal na Androidzie i komputerach. iOS nie był podatny. Źródłem problemu okazała się warstwa obsługująca różne identyfikatory kont, rozwijana wraz z uniezależnianiem komunikatora od ujawniania numerów telefonów i wprowadzeniem nazw użytkowników.

W uproszczeniu Signal musi rozróżniać różne rodzaje identyfikatorów powiązanych z tym samym kontem. W architekturze aplikacji występują między innymi identyfikatory odnoszące się do samego konta oraz do numeru telefonu. Samo istnienie kilku identyfikatorów nie jest błędem. Problem powstał w sposobie, w jaki klient traktował wiadomości podczas rozwiązywania i scalania tożsamości.

Złośliwy serwer mógł wykorzystać tę ścieżkę tak, aby klient zaakceptował przygotowany komunikat i przypisał go do rozmówcy. W rezultacie możliwe było wstrzyknięcie dowolnej wiadomości do rozmowy jeden na jeden.

Atak miał jednak ważne ograniczenie: nie był całkowicie niewidzialny. Signal wyświetlał użytkownikowi komunikat o zmianie numeru bezpieczeństwa — Safety Number. Takie ostrzeżenie powinno uruchomić procedurę ponownej weryfikacji rozmówcy.

Tu pojawiał się szczególnie podstępny element błędu. Jeśli użytkownicy po otrzymaniu ostrzeżenia rzeczywiście porównali swoje aktualne numery bezpieczeństwa, numery były poprawne i zgodne. Standardowa kontrola mogła więc wyglądać tak:

• pojawia się ostrzeżenie o zmianie Safety Number,

• rozmówcy kontaktują się innym kanałem,

• porównują aktualne wartości,

• wartości się zgadzają,

• użytkownicy uznają rozmowę za bezpieczną.

Problem polegał na tym, że podejrzana wiadomość mogła zostać wprowadzona wcześniej. Safety Number potwierdzał prawidłowość bieżącej relacji kryptograficznej między użytkownikami, ale nie cofał skutków wcześniejszego wstrzyknięcia wiadomości.

To praktycznie zmienia sposób, w jaki należy traktować alert dotyczący kluczy. Przy komunikacji wysokiego ryzyka nie wystarczy sprawdzić, czy po ostrzeżeniu numer znowu się zgadza. Trzeba również zakwestionować wiadomości pojawiające się bezpośrednio w okolicy zmiany tożsamości — szczególnie jeśli zawierają polecenie wykonania przelewu, przekazania dokumentu, kliknięcia odnośnika, ujawnienia kodu albo podjęcia decyzji operacyjnej.

Badacze zgłosili pierwszy problem Signalowi 22 września 2025 r. Poprawka dla Signal Desktop została przyjęta tego samego dnia, a dla Androida 24 września 2025 r. Mechanizm obronny sprowadzał się do odrzucania wiadomości dostarczanych niewłaściwą ścieżką identyfikatora.

Poprawki trafiły do:

• Signal Desktop 7.74.0-beta.1,

• Signal Android 7.58.0.

To nie są wersje, do których należy dziś celowo „cofać” aplikację. Są jedynie granicą historyczną pokazującą, od którego wydania dana poprawka została wprowadzona. Aktualny Signal powinien być instalowany z oficjalnego sklepu lub oficjalnego kanału dystrybucji i utrzymywany na bieżąco.

Błąd w Sealed Sender był poważniejszy: nie wymagał ostrzeżenia i obejmował grupy

Drugi atak jest znacznie ważniejszy z punktu widzenia zwykłego użytkownika. Dotyczył implementacji Sealed Sender na Androidzie i pozwalał złośliwemu serwerowi wstrzykiwać wiadomości zarówno do rozmów jeden na jeden, jak i do czatów grupowych.

Sealed Sender został wprowadzony w Signalu w 2018 r. po to, aby ograniczyć ilość metadanych dostępnych serwerowi. Przy standardowym przekazywaniu komunikatu infrastruktura pośrednicząca zna przynajmniej pewne informacje potrzebne do dostarczenia przesyłki. Sealed Sender przenosi identyfikację nadawcy do zaszyfrowanej części komunikatu, dzięki czemu serwer może dostarczyć wiadomość odbiorcy, nie otrzymując wprost pełnej informacji o tym, kto ją wysłał.

To dobry cel prywatnościowy, ale technicznie oznacza dodatkową warstwę opakowania wiadomości. A każda nowa warstwa zwiększa liczbę miejsc, w których trzeba pilnować jednej podstawowej zasady: tożsamość zweryfikowana kryptograficznie musi pozostać tą samą tożsamością na kolejnych etapach przetwarzania.

Badacze opisali kombinację dwóch błędów implementacyjnych:

• brakowało odpowiedniej kontroli klucza w jednej ze ścieżek przetwarzania,

• podczas przekazywania danych pomiędzy różnymi komponentami programu tracony był kontekst potrzebny do prawidłowego powiązania wiadomości z nadawcą.

To właśnie połączenie tych dwóch zachowań otwierało drogę do ataku. Nie chodziło więc o matematyczne złamanie szyfru ani odgadnięcie prywatnego klucza użytkownika. Serwer wykorzystywał niespójność pomiędzy kolejnymi etapami poprawnego kryptograficznie przetwarzania danych.

Najważniejsza różnica względem pierwszego wariantu była brutalnie prosta: użytkownik nie dostawał ostrzeżenia. Nie pojawiała się użyteczna informacja o zmianie Safety Number, którą można byłoby potraktować jako sygnał alarmowy.

Według autorów atak:

• mógł zostać wykonany w dowolnym momencie,

• nie wymagał specjalnych warunków wstępnych po stronie ofiary,

• umożliwiał wstrzykiwanie arbitralnych wiadomości,

• działał w rozmowach prywatnych,

• działał również w grupach,

• z perspektywy interfejsu użytkownika pozostawał niewykrywalny.

W praktyce grupa jest scenariuszem szczególnie problematycznym. Jeśli w prywatnym czacie pojawia się nietypowe polecenie od jednej osoby, odbiorca może jeszcze zadzwonić do niej i je potwierdzić. W kilkunastoosobowej grupie wiadomości są natomiast naturalnie traktowane jako element wspólnego zapisu rozmowy. Komunikat typu „wysyłamy dokument w tej wersji”, „zmieniamy numer rachunku”, „spotkanie przeniesione na 14:00” albo „zaakceptowane, wdrażamy” może uruchomić kolejne działania kilku osób, zanim ktokolwiek zacznie kwestionować jego pochodzenie.

Badacze ocenili, że podatność mogła istnieć od czasu wprowadzenia Sealed Sender w 2018 r. Nie oznacza to automatycznie, że była przez te lata aktywnie wykorzystywana. To dwie różne rzeczy: potwierdzenie możliwości technicznej nie jest dowodem prowadzenia ataków w rzeczywistych środowiskach.

Drugi problem został zgłoszony Signalowi 20 stycznia 2026 r. Poprawkę wydano osiem dni później, 28 stycznia 2026 r., w wersji Signal Android 7.72.2. iOS oraz oficjalny Signal Desktop nie były podatne na ten wariant.

Łatka dodała walidację danych po rozpakowaniu wiadomości Sealed Sender. To ważny szczegół projektowy: zamiast zakładać, że wcześniejszy etap obsługi pakietu zapewnił wszystkie wymagane gwarancje, klient ponownie sprawdza informacje w miejscu, w którym ma już wystarczający kontekst do podjęcia poprawnej decyzji.

Co faktycznie powinien zrobić użytkownik Signala po ujawnieniu tych błędów

Najgorszym wnioskiem byłoby uznanie, że „Signal został złamany” i należy natychmiast przesiąść się na inny komunikator. Badanie pokazuje coś bardziej precyzyjnego: konkretne wersje klientów miały błędy integralności, a błędy zostały usunięte. Zmiana aplikacji na produkt o słabiej przeanalizowanym protokole nie zwiększa automatycznie bezpieczeństwa.

Pierwszym zadaniem jest aktualizacja wszystkich urządzeń. Nie tylko telefonu.

Jeżeli ktoś używa Signala służbowo, powinien sprawdzić:

1. wersję Signala na każdym telefonie z Androidem,

2. wszystkie powiązane komputery,

3. urządzenia pracowników, którzy mogą długo odkładać aktualizacje,

4. nieoficjalne klienty i narzędzia automatyzujące komunikację,

5. procedurę potwierdzania wrażliwych poleceń przekazywanych na grupach.

Ten czwarty punkt łatwo przeoczyć. Autorzy sprawdzili także projekty bazujące na elementach ekosystemu Signala. signal-cli był podatny na drugi rodzaj ataku i został poprawiony w signal-cli 0.13.24. Wykorzystywana przez niego nieoficjalna biblioteka libsignal-service-java otrzymała poprawkę w wydaniu 2.15.3 unofficial 137. Projekt Whisperfish był natomiast podatny na pierwszy atak; poprawkę wprowadzono do jego głównej gałęzi pod koniec lutego 2026 r.

Dla osoby korzystającej wyłącznie z oficjalnej aplikacji te projekty nie mają większego znaczenia. Dla administratora, dziennikarza korzystającego z automatyzacji, zespołu SOC albo organizacji integrującej Signal z własnymi narzędziami to już realny punkt kontrolny. Aktualny telefon nie chroni starego bota działającego na serwerze.

Nie ma natomiast sensu masowo zmieniać Safety Numbers ze wszystkimi kontaktami tylko dlatego, że ujawniono ten błąd. W przypadku ataku Sealed Sender problem właśnie na tym polegał, że mechanizm nie musiał powodować ostrzeżenia dotyczącego numeru bezpieczeństwa. Ręczna weryfikacja nadal ma znaczenie dla potwierdzania tożsamości rozmówcy, ale nie była uniwersalnym antidotum na drugą podatność.

Dla rozmów, w których pojedyncza wiadomość może spowodować przelew pieniędzy, publikację materiału, przesłanie danych osobowych lub wydanie polecenia administracyjnego, rozsądniejsza jest zasada operacyjna: komunikator przekazuje informację, ale decyzja wysokiego ryzyka wymaga dodatkowego potwierdzenia. Może to być rozmowa głosowa, drugi kanał kontaktu albo ustalona wcześniej procedura zatwierdzania.

To szczególnie istotne w polskich firmach objętych wymaganiami NIS2, wewnętrznymi politykami bezpieczeństwa albo obowiązkami związanymi z ochroną danych. E2EE zmniejsza ryzyko podsłuchu treści w tranzycie, ale nie powinno być traktowane jako substytut procesu autoryzacji decyzji biznesowej.

Niedogodność jest oczywista: dodatkowe potwierdzanie spowalnia pracę. Nie należy więc potwierdzać telefonicznie każdej wiadomości „jestem pięć minut później”. Granica powinna być związana ze skutkiem wykonania polecenia. Osobno należy zatwierdzać przede wszystkim zmianę danych płatniczych, przekazanie hasła lub kodu, eksport danych, wysłanie poufnego pliku, zmianę uprawnień oraz działanie, którego później trudno odwrócić.

Dodatkowe informacje na: [ANCHOR].

FAQ — najważniejsze pytania o podatności Signala

Czy badacze złamali szyfrowanie end-to-end Signala?
Nie. Ataki dotyczyły integralności i sposobu wiązania wiadomości z tożsamością nadawcy. Nie polegały na odszyfrowywaniu cudzej korespondencji przez złamanie używanych algorytmów kryptograficznych.

Czy serwer Signala mógł dowolnie czytać wszystkie wiadomości?
Nie. Opisane podatności umożliwiały wstrzykiwanie wiadomości w określonych ścieżkach przetwarzania. To inna klasa problemu niż dostęp serwera do tekstu istniejącej zaszyfrowanej korespondencji.

Czy drugi atak działał na czatach grupowych?
Tak. Wariant związany z Sealed Sender pozwalał na Androidzie wprowadzić przygotowaną wiadomość zarówno do rozmowy jeden na jeden, jak i do konwersacji grupowej.

Czy użytkownik widział ostrzeżenie?
W pierwszym ataku pojawiał się alert o zmianie Safety Number. W drugim, poważniejszym wariancie związanym z Sealed Sender użytkownik nie otrzymywał odpowiedniego ostrzeżenia.

Czy iPhone był podatny?
Nie na opisane w pracy warianty. Pierwszy atak dotyczył Androida i Desktopu, natomiast drugi oficjalnego klienta Signal na Androida.

Od jakiej wersji Android jest poprawiony?
Pierwszy błąd został usunięty w Signal Android 7.58.0, a podatność Sealed Sender w 7.72.2. W praktyce nie należy instalować tych starych wydań — trzeba korzystać z najnowszej dostępnej wersji aplikacji.

Czy trzeba ponownie weryfikować Safety Number ze wszystkimi kontaktami?
Nie. Aktualizacja klienta ma wyższy priorytet. Safety Number warto weryfikować przy rozmowach szczególnie wrażliwych oraz po nieoczekiwanym ostrzeżeniu o zmianie tożsamości, ale sama ręczna weryfikacja nie usuwała problemu Sealed Sender.

Czy istnieją dowody, że podatność była wykorzystywana przeciw użytkownikom?
Opis badań pokazuje praktyczną możliwość wykonania ataków, ale nie dowodzi masowego wykorzystania tych konkretnych luk w realnych kampaniach.

Co sprawdzić jako pierwsze?
Najpierw wersję Signala na wszystkich urządzeniach z Androidem oraz wszystkich powiązanych klientach i integracjach. W środowisku firmowym trzeba zacząć od sprzętu, który nie aktualizuje aplikacji automatycznie. Dopiero później warto porządkować procedury weryfikowania rozmówców. Najgroźniejszym błędem do usunięcia nie jest dziś ustawienie prywatności w interfejsie, lecz pozostawienie starego klienta — zwłaszcza Androida sprzed poprawki 7.72.2 albo zapomnianej integracji opartej na nieaktualnym signal-cli.