Wprowadzenie do problemu / definicja
W aplikacjach do bezpiecznej komunikacji użytkownicy zakładają, że naciśnięcie przycisku zakończenia połączenia natychmiast odcina transmisję audio i wideo. Opisana podatność w Signal podważa to założenie, ponieważ dotyczyła logiki zamykania sesji VoIP, a nie samego szyfrowania end-to-end. W praktyce mogło to oznaczać sytuację, w której rozmowa wydawała się zakończona, ale mikrofon, a w określonych scenariuszach także kamera, pozostawały aktywne dłużej, niż oczekiwał użytkownik.
W skrócie
Podatność została oznaczona jako CVE-2026-113380 i oceniona wysoko w skali CVSS. Źródłem problemu była biblioteka RingRTC wykorzystywana przez Signal do obsługi połączeń głosowych i wideo. Błąd umożliwiał złośliwemu uczestnikowi rozmowy zakłócenie procesu rozłączenia przez przeciążenie kolejki zdarzeń kontrolnych, co mogło opóźnić realizację lokalnego polecenia zakończenia połączenia.
- Problem dotyczył logiki rozłączania, a nie złamania szyfrowania.
- Zagrożone były starsze wersje RingRTC oraz odpowiadające im wydania klientów Signal.
- Najważniejszym działaniem ochronnym jest aktualizacja aplikacji do poprawionych wersji.
Kontekst / historia
Incydent zwraca uwagę na klasę błędów, które nie naruszają bezpośrednio kryptografii, ale osłabiają bezpieczeństwo operacyjne i prywatność użytkowników. Signal jest powszechnie postrzegany jako komunikator o wysokim poziomie ochrony, dlatego każda podatność związana z kontrolą połączenia ma istotne znaczenie dla zaufania do platformy.
W tym przypadku problem nie polegał na odszyfrowaniu treści rozmowy ani przejęciu kluczy. Sednem luki była niewłaściwa semantyka kończenia sesji. Użytkownik podejmował decyzję o rozłączeniu na podstawie sygnału z interfejsu, oczekując natychmiastowego odcięcia dostępu do urządzeń wejściowych. Jeżeli jednak aplikacja traktowała lokalne żądanie zakończenia połączenia jak zwykłe zdarzenie w kolejce, zdalny uczestnik mógł wpłynąć na moment rzeczywistego zamknięcia sesji.
Analiza techniczna
Z technicznego punktu widzenia problem wynikał ze sposobu zarządzania stanem połączenia w RingRTC przy użyciu maszyny stanów i kolejki zdarzeń. Akcja „rozłącz” nie była realizowana jako bezwzględny mechanizm natychmiastowego zatrzymania połączenia, lecz jako kolejne zdarzenie oczekujące na przetworzenie. Jeśli zdalny uczestnik generował dużą liczbę własnych zdarzeń, mógł zapełnić kolejkę i opóźnić obsługę polecenia zakończenia rozmowy po stronie ofiary.
To klasyczny problem projektowy związany z priorytetyzacją operacji krytycznych. W systemach obsługujących multimedia i sygnały sterujące zdarzenia odpowiedzialne za odcięcie dostępu do mikrofonu i kamery powinny być traktowane priorytetowo albo obsługiwane poza standardową ścieżką kolejkowania. W przeciwnym razie atakujący nie musi łamać zabezpieczeń kryptograficznych, lecz jedynie wymusić niekorzystne zachowanie logiki aplikacyjnej.
Istotne jest również rozróżnienie między kompromitacją poufności kanału a błędem sterowania sesją. Szyfrowanie end-to-end nadal chroni treść przesyłanych danych przed podsłuchem pośrednim, ale nie eliminuje ryzyka, że aplikacja będzie nadal legalnie transmitować audio lub wideo, jeśli sesja nie została skutecznie zamknięta.
Według dostępnych informacji problem obejmował RingRTC w wersjach wcześniejszych niż 2.72.0. Wskazywano także na podatne wersje klientów Signal dla Androida, iOS i desktopa, które zostały później poprawione przez producenta.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności było naruszenie prywatności. Użytkownik mógł zakończyć rozmowę w przekonaniu, że transmisja została już przerwana, podczas gdy druga strona nadal mogła przez pewien czas odbierać dźwięk lub obraz. W środowiskach wysokiego ryzyka, takich jak media, sektor prawny, administracja czy komunikacja korporacyjna, taka luka mogła prowadzić do ujawnienia wrażliwych informacji.
Ryzyko było tym bardziej istotne, że atak nie wymagał instalacji złośliwego oprogramowania po stronie ofiary. Wystarczył udział atakującego w połączeniu i możliwość generowania zdarzeń wpływających na kolejkę sterującą. Ograniczało to wektor ataku do aktywnego uczestnika rozmowy, ale jednocześnie czyniło scenariusz realnym w przypadku ataków ukierunkowanych lub działań socjotechnicznych.
Dla organizacji oznacza to również konieczność ponownej oceny procedur bezpieczeństwa. Jeżeli komunikatory są wykorzystywane do omawiania danych poufnych, luka wpływająca na pewność rozłączenia może wymagać aktualizacji polityk zarządzania ryzykiem, aktualizacjami i użyciem urządzeń końcowych.
Rekomendacje
Podstawowym zaleceniem jest niezwłoczna aktualizacja Signal do wersji zawierających poprawkę oraz upewnienie się, że wykorzystywana biblioteka RingRTC została zaktualizowana do bezpiecznego wydania. W praktyce organizacje powinny potraktować ten typ błędu jako istotny problem prywatności, a nie wyłącznie jako usterkę funkcjonalną.
- wymuszać szybkie aktualizacje komunikatorów na urządzeniach firmowych,
- monitorować inwentarz aplikacji pod kątem wersji klientów i bibliotek VoIP,
- traktować funkcję „hang up” jako element krytyczny podczas audytów bezpieczeństwa,
- ograniczać uprawnienia do mikrofonu i kamery tam, gdzie nie są stale potrzebne,
- korzystać z systemowych wskaźników aktywności mikrofonu i kamery jako dodatkowej warstwy kontroli,
- stosować procedury operacyjne wymagające fizycznego wyciszenia mikrofonu lub całkowitego zamknięcia aplikacji po rozmowach o wysokiej wrażliwości.
Z perspektywy producentów oprogramowania to kolejny argument za wdrażaniem mechanizmów fail-safe. Zakończenie połączenia powinno być realizowane natychmiast, w sposób odporny na przeciążenie kolejki i niewrażliwy na manipulację ze strony zdalnego uczestnika.
Podsumowanie
Podatność w Signal nie oznaczała złamania szyfrowania end-to-end, ale ujawniła poważny problem w warstwie sterowania połączeniami. W praktyce błąd mógł sprawić, że użytkownik kończył rozmowę tylko pozornie, a transmisja audio lub wideo trwała nadal. To ważne przypomnienie, że bezpieczeństwo komunikatora zależy nie tylko od kryptografii, lecz także od poprawnej logiki aplikacyjnej, przewidywalnego zachowania interfejsu i właściwej obsługi zdarzeń krytycznych.
Źródła
- Security Affairs — https://securityaffairs.com/201490/security/signal-vulnerability-could-keep-calls-alive-after-users-hang-up.html
- NVD CVE-2026-113380 — https://nvd.nist.gov/vuln/detail/CVE-2026-113380
- signalapp/ringrtc Release v2.72.0 — https://github.com/signalapp/ringrtc/releases/tag/v2.72.0
- CSIRT Toscana — Signal: vulnerabilità critica che può lasciare microfono e camera attivi dopo la chiusura della chiamata — https://csirt.regione.toscana.it/alert/signal-vulnerabilita-critica-che-puo-lasciare-microfono-e-camera-attivi-dopo-la-chiusura-della-chiamata/