Luka w aktualizacjach Molly budzi obawy o bezpieczeństwo starszej biblioteki połączeń Signal

Molly od trzech miesięcy nie opublikowało stabilnego wydania, co rodzi pytania, czy dodatkowe zabezpieczenia nie wiążą się z opóźnionymi poprawkami bezpieczeństwa. Luka w aktualizacjach Molly zasługuje na analizę, ponieważ lipcowe wydanie deklaruje starszą bibliotekę połączeń niż wersja rozwiązująca opublikowaną podatność dotyczącą kończenia rozmów.

Według stanu na 2 listopada 2026 r. publicznie dostępne dowody uzasadniają obawy dotyczące starzejącego się wydania i potencjalnie podatnej zależności. Nie dowodzą jednak, że atakujący wykorzystali użytkowników Molly. Nie rozstrzygają też, czy dostosowana biblioteka Molly zawiera równoważną poprawkę.

Główne napięcie dotyczy dodatkowych funkcji bezpieczeństwa i terminowego utrzymania oprogramowania. Signal dostarcza kod upstream, czyli oryginalne oprogramowanie adaptowane przez Molly. Użytkownicy Molly zależą od innego procesu wydawniczego, aby otrzymywać te zmiany. Fork skoncentrowany na bezpieczeństwie, czyli niezależnie utrzymywany wariant oprogramowania, musi zapewniać niezawodność tego procesu obok własnych zabezpieczeń.

Co faktycznie pokazuje luka w aktualizacjach Molly

Publiczna lista wydań Molly na GitHubie wskazuje v8.19.2-4 z datą 31 lipca jako najnowsze wydanie. W notatkach opisano poprawkę wycieku DNS, czyli niezamierzonego ujawnienia zapytań o domeny, gdy używany był skonfigurowany serwer proxy. Oznacza to, że widoczne stabilne wydanie jest o ponad trzy miesiące starsze niż data publikacji tego artykułu. Historia wydań potwierdza główne twierdzenie dotyczące czasu.

Luka między wydaniami jest weryfikowalna; jej konsekwencje dla bezpieczeństwa wymagają odrębnej analizy.

To rozróżnienie ma znaczenie, ponieważ daty wydań odpowiadają na węższe pytanie, niż często sugerują nagłówki. Ustalają, kiedy projekt opublikował pakiet za pośrednictwem określonego kanału. Nie ujawniają automatycznie każdej zmiany zawartej w tym pakiecie.

Starsze wydanie może zawierać selektywnie zaimportowaną poprawkę bezpieczeństwa. Deweloperzy nazywają to backportem: zastosowaniem późniejszej korekty bez wdrażania całego nowszego wydania. Z kolei niedawno opublikowany pakiet może zachować przestarzałą zależność.

Dla czytelników użyteczne pytanie jest więc bardziej konkretne niż to, czy Molly sprawia wrażenie nieaktywnego. Chodzi o to, czy zainstalowana aplikacja zawiera poprawkę dla omawianej podatności.

Publiczne obawy pojawiły się w poście społeczności udostępnionym wraz z briefem do tej historii. Jego tytuł zarzuca zarówno trzymiesięczną przerwę w aktualizacjach, jak i istnienie podatności. Te twierdzenia powinny być weryfikowane oddzielnie, nawet jeśli występują razem w nagłówku dyskusji.

Lista wydań potwierdza pierwsze twierdzenie. Ustalenie drugiego wymaga porównania komponentów aplikacji z udokumentowaną wadą, a następnie sprawdzenia równoważnych poprawek.

Takie podejście ogranicza również to, co można odpowiedzialnie powiedzieć o samym projekcie. Cicha strona wydań nie dowodzi, że jego opiekunowie porzucili rozwój. Nie wyjaśnia ich dostępności, wewnętrznych testów ani przeszkód w publikowaniu wydań.

Nie ustalono tu żadnego zweryfikowanego wyjaśnienia tej przerwy. Przypisanie go oznaczałoby przekształcenie obserwowalnego problemu z utrzymaniem w spekulacje na temat odpowiedzialnych osób.

Mimo to użytkownicy nie potrzebują wyjaśnienia, aby dostrzec, że dostępny pakiet się starzeje. Prywatny wysiłek rozwojowy nie zapewnia wdrożonej ochrony, dopóki poprawiona aplikacja nie trafi na ich urządzenia.

Dlatego ta luka ma teraz znaczenie. Praktyczne pytanie dotyczy oprogramowania, które ludzie mogą zainstalować, a nie intencji stojących za pracą, której nie mogą sprawdzić.

Dla każdego, kto śledzi tę historię, lipcowa data powinna być punktem wyjścia dochodzenia. Rekord zależności dostarcza kolejnego, bardziej istotnego dowodu.

Starsza zależność obsługująca połączenia konkretyzuje obawy

Źródło powiązane z Molly v8.19.2-4 deklaruje zależność Android RingRTC jako im.molly:ringrtc-android:2.69.5-1. RingRTC to biblioteka oprogramowania obsługująca funkcje połączeń związane z Signal. Oznaczona zależność połączeń wskazuje konkretny komponent do zbadania.

Opublikowany wpis dotyczący podatności, CVE-2026-113380, identyfikuje problem z kończeniem rozmów w wersjach upstream RingRTC wcześniejszych niż 2.72.0. CVE to publiczny identyfikator używany do śledzenia ujawnionej podatności. Wpis opisuje zakłócenie przetwarzania rozłączenia, gdy inny uczestnik rozmowy nasyca wewnętrzną kolejkę. Dźwięk, a być może także obraz, może nadal pozostawać aktywny. Ostrzeżenie dotyczące kończenia rozmów opublikowano 20 października.

Zadeklarowana zależność nadaje tej historii techniczną podstawę wykraczającą poza wiek aplikacji.

Zależność Molly używa jednak własnej przestrzeni nazw pakietów projektu oraz przyrostka wersji. Tworzy to istotną granicę weryfikacji. Jej numer plasuje ją poniżej naprawionej wersji upstream, lecz sam numer nie dowodzi identycznej zawartości kodu źródłowego.

Rozstrzygająca ocena wymagałaby zbadania dokładnej biblioteki użytej do zbudowania rozpowszechnianej aplikacji. Należałoby ustalić, czy obecna jest odpowiednia poprawka albo funkcjonalnie równoważna zmiana.

Ten artykuł nie przeprowadził jeszcze takiego badania na poziomie artefaktu. Artefakt to faktycznie rozpowszechniany plik oprogramowania, a nie lista źródeł opisująca sposób jego zbudowania.

Dowody potwierdzają zatem potencjalnie podatną zależność i potrzebę wyjaśnień. Nie uzasadniają przedstawiania skutecznego ataku wymierzonego konkretnie w Molly jako niezależnie wykazanego.

To rozróżnienie jest przydatne dla użytkowników rozważających poufne rozmowy. Potrzebują odpowiedzi dotyczącej komponentu działającego na ich telefonach. Ogólne zapewnienie o szyfrowaniu nie odpowiadałoby na to pytanie.

Szyfrowanie end-to-end, które chroni treść między komunikującymi się punktami końcowymi, samo w sobie nie przesądza, czy punkt końcowy przestaje transmitować po otrzymaniu takiego polecenia. Rozmowa może pozostawać zaszyfrowana, jednocześnie zachowując się niezgodnie z oczekiwaniami uczestnika.

Wyobraźmy sobie hipotetycznego badacza kończącego wywiad przed omówieniem poufnych materiałów z osobą znajdującą się w pobliżu. Granicą prywatności jest moment, w którym mikrofon przestaje wysyłać dźwięk.

Jeśli ta granica zawiedzie, silna ochrona podczas transmisji nie przywraca zamierzonej przez użytkownika kontroli. Ten scenariusz ilustruje znaczenie zgłoszonej wady; nie jest udokumentowanym incydentem dotyczącym Molly.

To samo rozróżnienie ma znaczenie w rozmowach służbowych, wywiadach ze źródłami i rozmowach prywatnych. Użytkownicy podejmują decyzje na podstawie tego, czy ich udział się zakończył, często bez sprawdzania podstawowego stanu aplikacji.

Dla deweloperów natychmiastowe zadanie jest konkretne. Wykazanie obecności poprawki rozwiałoby więcej wątpliwości niż porównywanie numerów wersji aplikacji czy powtarzanie ogólnych twierdzeń o bezpieczeństwie.

Dodatkowe wzmocnienia nadal zależą od utrzymania

Molly opisuje się jako wariant Signal skoncentrowany na bezpieczeństwie. Jego dokumentacja wymienia ochronę hasłem dostępu do bazy danych, automatyczne blokowanie, wymazywanie pamięci oraz alternatywy dla odbierania powiadomień. Ta sama dokumentacja mówi, że rutynowe aktualizacje pojawiają się co dwa tygodnie, a poprawki bezpieczeństwa są stosowane, gdy są dostępne. Są to deklarowane funkcje projektu i zobowiązania dotyczące utrzymania, a nie niezależna weryfikacja ich skuteczności. Jego zobowiązania dotyczące bezpieczeństwa ustanawiają standard, któremu użytkownicy mają zaufać.

Dodatkowe zabezpieczenia i terminowe poprawki dotyczą różnych zagrożeń, a użytkownicy potrzebują odrębnej oceny obu tych kwestii.

Wzmocnienia oznaczają dodawanie środków mających zmniejszać ekspozycję lub ograniczać szkody. Blokada bazy danych dotyczy na przykład dostępu do informacji przechowywanych na urządzeniu. Poprawka biblioteki połączeń dotyczy zachowania podczas komunikacji.

Sukces w jednym obszarze nie dowodzi bezpieczeństwa w drugim. Lista funkcji nie może odpowiedzieć na pytanie, czy określony podatny komponent został poprawiony.

To kluczowy kompromis w dyskusji Molly kontra Signal. Użytkownicy wybierający zmodyfikowanego klienta mogą zyskać cenione przez siebie mechanizmy kontroli, jednocześnie akceptując proces integracji i dystrybucji innego projektu.

Ta zależność nie czyni forków z natury niebezpiecznymi. Oznacza, że ich argumentacja dotycząca bezpieczeństwa obejmuje bieżącą pracę operacyjną obok projektu dodatkowych funkcji.

Poprawka upstream musi zostać przejrzana, zintegrowana, zbudowana, przetestowana, podpisana i dostarczona. Podpisywanie przypisuje tożsamość wydawcy do pakietu oprogramowania, aby urządzenia mogły rozpoznawać autoryzowane aktualizacje.

Każdy etap może być rozsądny sam w sobie. Łącznie te etapy określają, jak długo użytkownicy czekają, zanim opublikowana poprawka stanie się zainstalowaną ochroną.

Koszt jest szczególnie istotny, gdy modyfikacje dotyczą tych samych obszarów co rozwój upstream. Deweloperzy muszą zachować własne zmiany, jednocześnie sprawdzając, czy nowy kod działa z nimi poprawnie.

Nie należy traktować tej pracy jako administracyjnego narzutu. Inżynieria wydań stanowi część granicy bezpieczeństwa produktu, ponieważ użytkownicy zależą od wynikowego pakietu.

Dla osoby pytającej „czy Molly Signal jest bezpieczny” odpowiedź zależy więc od rozważanego ryzyka. Ochrona przed przypadkowym dostępem do zapisanych wiadomości różni się od niezawodnego radzenia sobie z wrogimi uczestnikami rozmowy.

Przydatna ocena pyta, które zabezpieczenia mają znaczenie, jaka wersja jest zainstalowana i jakie dowody potwierdzają jej status utrzymania. Jeden przymiotnik nie może odpowiedzialnie połączyć tych odpowiedzi.

Główny Signal stanowi punkt odniesienia, ponieważ utrzymuje oryginalną aplikację i bibliotekę połączeń. Ta relacja eliminuje etap integracji downstream, choć nie oznacza braku podatności.

Molly musi tymczasem uzasadnić dodatkową zależność od utrzymania korzyściami, których jego użytkownicy rzeczywiście potrzebują. Uzasadnienie to staje się trudniejsze, gdy status komponentów pozostaje niepewny.

Uczciwe porównanie dotyczy obecnego, weryfikowalnego działania. Powinno unikać założenia, że zmodyfikowany klient jest bezpieczniejszy, ponieważ dodaje mechanizmy kontroli, albo że oryginalny klient jest bezbłędny.

Natychmiastowa presja spoczywa na procesie wydawniczym Molly. Deklarowane przez projekt oczekiwania dotyczące utrzymania sprawiają, że widoczna przerwa ma znaczenie niezależnie od jej przyczyn.

Poprawka upstream zmienia priorytet kończenia rozmów

Powiązana poprawka RingRTC od Signal dodaje oddzielną flagę żądania zakończenia i sprawdza zakończenie niezależnie od zwykłego przetwarzania kolejki. Flaga to zapisany znacznik stanu, który kod może bezpośrednio sprawdzić. Zmiana wprowadza również ograniczone czasowo oczekiwanie i pozwala kontynuować czyszczenie po wystąpieniu określonych błędów. Szczegóły te widoczne są w poprawce upstream dotyczącej zakończenia.

Znaczenie techniczne polega na rozdzieleniu żądania zakończenia rozmowy od oczekiwania za inną pracą. Poprawka sprawia, że zakończenie jest mniej zależne od normalnego postępu kolejki.

Decyzja użytkownika o zakończeniu udziału wymaga niezawodnego egzekwowania nawet wtedy, gdy inny uczestnik generuje nieoczekiwaną aktywność.

Kolejka to struktura przechowująca pracę, dopóki oprogramowanie jej nie przetworzy. Kolejki są powszechne i użyteczne, lecz ich kolejność może mieć znaczenie, gdy pilne działania lokalne współdzielą przetwarzanie ze zdarzeniami, na które zdalnie można wpływać.

W tym przypadku pytanie dotyczące bezpieczeństwa dotyczy tego, kto faktycznie kontroluje opóźnienie. Lokalny uczestnik oczekuje, że aplikacja wykona działanie rozłączenia, nawet w nietypowych warunkach.

To sprawia, że problem różni się od zwykłej usterki użyteczności. Opóźniona animacja jest niewygodna. Opóźnione wykonanie decyzji dotyczącej prywatności może ujawnić informacje, które uczestnik zamierzał zachować dla siebie.

Szersza lekcja jest inżynierskim wnioskiem płynącym z tej poprawki. Mechanizmy kończące wrażliwe działania zasługują na wyraźne traktowanie, gdy oprogramowanie obsługuje sprzeczne lub wrogie dane wejściowe.

Ta zasada ma zastosowanie nie tylko w komunikatorach. Polecenie zatrzymania nagrywania, unieważnienie sesji lub cofnięcie uprawnienia mogą wiązać się z podobnymi oczekiwaniami. Każde z nich wymaga odrębnego przeglądu implementacji; ta podatność nie dowodzi wad w tych innych systemach.

W tej historii wniosek pozostaje skoncentrowany na rozmowach. Istotne pytanie brzmi, czy rozproszzona biblioteka Molly zawiera zachowanie kończące połączenie wprowadzone przez poprawkę.

Nowszy interfejs aplikacji nie rozstrzygałby tej kwestii. Nie rozstrzygałyby jej również udane zwykłe rozmowy, ponieważ normalne działanie nie musi uruchamiać omawianego warunku awarii.

Przydatna walidacja musi zbadać sam stan nieprawidłowy. Powinna wykazać, że lokalne żądanie zakończenia skutkuje ukończonym sprzątaniem zasobów, gdy zwykłe przetwarzanie się zatrzymuje lub zostaje przeciążone.

Dlatego zmiana w kodzie źródłowym, zapis kompilacji i ukierunkowany test regresji byłyby łącznie przekonujące. Test regresji weryfikuje, czy wcześniej zidentyfikowana awaria nie powraca.

Te formy dowodów odpowiadają na różne pytania. Kod źródłowy określa zamierzone zachowanie. Zapis kompilacji łączy ten kod z pakietem. Testowanie sprawdza, czy dane zachowanie działa.

Użytkownicy nie powinni musieć samodzielnie przeprowadzać całej tej analizy. Oświadczenie opiekuna projektu wskazujące poprawkę i dotknięte nią wydania dałoby im praktyczną podstawę do decyzji, co zainstalować.

Mechanizm wyjaśnia również, dlaczego wiek kalendarzowy ma znaczenie jedynie pośrednie. Upływ czasu stwarza możliwość rozbieżności, ale o tej konkretnej kwestii technicznej decyduje obecność lub brak poprawki.

Co pozostaje niezweryfikowane w kwestii narażenia Molly

Dostępne dane pozostawiają kilka pytań otwartych. W tym przeglądzie nie odtworzono niezależnie CVE-2026-113380 przeciwko Molly v8.19.2-4. Nie ustalono też, czy dostosowana biblioteka do rozmów Molly zawiera równoważny backport.

Nie ustalono również skutecznego ataku na użytkownika Molly. Ostrzeżenie o podatności, wniosek dotyczący dotkniętego komponentu i dowody wykorzystania to różne ustalenia.

Najmocniej poparty wniosek to udokumentowana luka wydawnicza z konkretną, nierozstrzygniętą kwestią dotyczącą komponentu.

Ten wniosek jest wystarczająco poważny, by uzasadniać analizę, bez rozszerzania go o niepoparte twierdzenia. Stwierdzenie, że każdy użytkownik Molly był monitorowany, wykraczałoby daleko poza dostępne dowody.

Podobnie ta kwestia dotycząca rozmów nie dowodzi, że zapisane historie wiadomości zostały odszyfrowane. Zgłoszony mechanizm dotyczy zakończenia aktywnej sesji komunikacyjnej.

Precyzyjne określenie zakresu pomaga użytkownikom podejmować proporcjonalne decyzje. Osoba oceniająca prywatność rozmów potrzebuje innych informacji niż ktoś badający przechowywanie wiadomości lub dostęp do konta.

Opis w poradniku dotyczy innego uczestnika rozmowy. Nie opisuje sytuacji, w której przypadkowi obcy zdalnie aktywują każdy zainstalowany mikrofon bez istniejącej interakcji.

Ta granica powinna pozostać widoczna przy każdym streszczeniu tej historii. Usunięcie warunków ataku może sprawić, że ostrzeżenie zabrzmi bardziej dramatycznie, jednocześnie czyniąc je mniej użytecznym.

Brak odtworzonego exploita specyficznego dla Molly również nie powinien być traktowany jako uspokojenie. Użytkownicy nie muszą czekać na publicznie ujawnioną szkodę, zanim będą oczekiwać dowodów, że istotna poprawka została wydana.

W tym miejscu ostrożna odpowiedź na pytanie „czy Molly Signal jest bezpieczny” musi oprzeć się binarnemu werdyktowi. Dowody wskazują pytanie o konkretne wydanie i komponent, a nie trwałą ocenę projektu.

Nie ma tu również zweryfikowanych podstaw, by przypisywać opóźnienie zaniedbaniu, problemom z finansowaniem, chorobie lub porzuceniu projektu. Takie wyjaśnienia wymagają oświadczeń lub zapisów, które je potwierdzają.

Opiekunowie projektu mogą mierzyć się z uzasadnionymi ograniczeniami, ale użytkownicy nadal odczuwają skutki opóźnionego dostarczania aktualizacji. Zrozumienie przyczyny i ocena wydania to odrębne zadania.

Porównanie Molly z Signal powinno pozostać równie zdyscyplinowane. Własność projektu nadrzędnego nie gwarantuje doskonałego bezpieczeństwa, podobnie jak dodatkowe wzmocnienia nie usprawiedliwiają niepewności co do znanych poprawek.

Dla organizacji oznacza to potrzebę oceny dokładnych kompilacji aplikacji w wrażliwych procesach. Zatwierdzona nazwa produktu nie wystarcza, gdy różni klienci i wydania zawierają inne oprogramowanie.

Dla osób indywidualnych oznacza to konieczność sprawdzenia rzeczywistej aplikacji i kanału aktualizacji przed przyjęciem założeń. Uspokajająca ikona lub znajoma lista kontaktów nie identyfikują bazowej zależności.

Najlepsza odpowiedź zawęziłaby niepewność za pomocą dowodów. Udokumentowany backport osłabiłby wniosek dotyczący dotkniętego komponentu. Odtwarzalna awaria by go wzmocniła. Oba te elementy poprawiłyby dyskusję.

Trzy sygnały zadecydują o odzyskaniu zaufania

Luka aktualizacyjna Molly stanie się łatwiejsza do oceny, gdy publiczne zapisy połączą istotną poprawkę z oprogramowaniem, które użytkownicy mogą uzyskać. Kolejna debata o ogólnych preferencjach prywatności nie rozwiąże tej kwestii.

Kolejnymi użytecznymi wydarzeniami będą poprawione wydanie, wyraźne wyjaśnienie techniczne oraz dowody na trwałe dostarczanie aktualizacji.

Pierwszym sygnałem jest publicznie dostępny pakiet Molly z jasno udokumentowaną poprawką biblioteki rozmów. Wydanie nadrzędnego RingRTC wersja 2.72.0 stanowi punkt odniesienia dla tego dochodzenia. Równoważny backport również może mieć znaczenie, pod warunkiem że jego zawartość jest udokumentowana.

Wzmocniłoby to zaufanie do konkretnego pakietu poprzez bezpośrednie zajęcie się kwestią komponentu. Nowa wersja bez istotnych informacji o zależnościach pozostawiłaby recenzentom więcej pracy.

Dystrybucja jest ważna obok publikacji. Użytkownicy potrzebują poprawionego pakietu w kanale, z którego faktycznie korzystają, oraz wystarczających informacji, by rozpoznać, że uwzględniono istotną zmianę.

Drugim sygnałem jest wyjaśnienie opiekuna projektu wskazujące dotknięte kompilacje i status poprawki. Takie oświadczenie byłoby najbardziej użyteczne, gdyby łączyło zmiany w kodzie źródłowym, identyfikatory wydań i dostępną walidację.

Oświadczenie potwierdzające istniejący backport istotnie osłabiłoby wniosek, że lipcowy pakiet zachowuje tę wadę. Oświadczenie potwierdzające narażenie wyjaśniłoby, którzy użytkownicy muszą podjąć działania.

Każdy z tych wyników poprawiłby publiczny zapis. Precyzja techniczna jest cenniejsza niż ogólne zapewnienie, że bezpieczeństwo pozostaje priorytetem.

Trzecim sygnałem będzie to, co nastąpi po rozwiązaniu bezpośredniego problemu. W nadchodzących miesiącach regularne wydania i wyraźne traktowanie zmian związanych z bezpieczeństwem pokażą, czy dostarczanie aktualizacji znów stało się niezawodne.

Jedno wydanie nadrabiające zaległości może rozwiązać pilny problem. Nie może jednak samo w sobie wykazać, jak projekt poradzi sobie z kolejną poprawką.

Powtarzające się opóźnienia wzmocniłyby obawy dotyczące zależności od utrzymania projektu. Konsekwentne dostarczanie osłabiłoby argument, że użytkownicy muszą akceptować długotrwałą niepewność, aby zachować dodatkowe mechanizmy Molly.

Ten ostatni sygnał ma znaczenie, ponieważ zaufanie obejmuje oczekiwania dotyczące przyszłego zachowania. Użytkownicy nie mogą dziś sprawdzić jutrzejszego kodu, ale mogą ocenić, czy projekt komunikuje się jasno i przewidywalnie dostarcza poprawki.

Dla deweloperów utrzymujących inne forki skoncentrowane na bezpieczeństwie te same dowody stanowią praktyczny punkt odniesienia. Wyjaśniajcie status komponentów, wskazujcie dotknięte pakiety i uwidaczniajcie drogę od poprawki do instalacji.

Czytelnicy powinni opierać decyzję na dowodach, które mogą sprawdzić: zainstalowanej wersji, jej udokumentowanych komponentach oraz statusie istotnych poprawek. Nie traktujcie listy funkcji jako substytutu takiego zapisu. Jeśli prywatność rozmów ma znaczenie dla waszej pracy lub bezpieczeństwa osobistego, nadajcie nierozstrzygniętym kwestiom utrzymania odpowiednią wagę przy wyborze klienta. Śledźcie kolejne wydanie i jego informacje techniczne, a następnie wróćcie do decyzji, gdy te zapisy się zmienią. Luka aktualizacyjna Molly rodzi konkretne pytanie, które zasługuje na konkretną odpowiedź: czy aplikacja na waszym urządzeniu zawiera poprawkę potrzebną do niezawodnego zakończenia rozmowy?