Na błąd GhostMap, przez który jedna zainstalowana aplikacja może wpędzić telefon z Androidem w pętlę restartów, Google nie wyda poprawki bezpieczeństwa. Z takiej pętli wychodzi się praktycznie tylko resetem do ustawień fabrycznych, który kasuje dane z telefonu. Opisał to 5 listopada 2026 roku Bitdefender Labs. Według firmy aplikacja nie zawiera kodu, nie prosi o żadne uprawnienia i nie trzeba jej otwierać, a problem dotyczy Androida 10 i nowszych. Google uznało zgłoszenie za sprawę spoza zakresu poprawek bezpieczeństwa i przekazało je zespołowi od funkcji systemu. Ataków z użyciem tej techniki Bitdefender nie widział, więc dziś najważniejsza ochrona to aktualna kopia zapasowa i nieinstalowanie plików APK z linków. Stan na 5 listopada 2026 roku, godz. 17:15, według raportu Bitdefender Labs, relacji BleepingComputer i stron pomocy Google.
GhostMap: co odkrył Bitdefender
GhostMap to błąd w sposobie, w jaki Android czyta pliki instalacyjne aplikacji (APK), opisany w raporcie Bitdefender Labs z 5 listopada 2026 roku. Autorem jest Alecsandru Cătălin Daj, szef zespołu bezpieczeństwa mobilnego w Bitdefenderze. Niezależnego potwierdzenia na razie nie ma, więc wszystko, co niżej, jest relacją z tego raportu.
Plik APK to w praktyce archiwum ZIP. Każdy plik w środku ma zapisaną metodę kompresji i rozmiar po rozpakowaniu. Według Bitdefendera dwie biblioteki Androida inaczej rozumieją nietypową metodę kompresji. Jedna nie sprawdza zadeklarowanego rozmiaru, druga ufa mu bez sprawdzenia. System tworzy wtedy mapowanie pamięci większe niż rzeczywisty plik. Gdy proces próbuje odczytać obszar za końcem pliku, dostaje sygnał SIGBUS i pada. W opisanym teście plik miał 8 408 bajtów, a Android zmapował go na około 16 MB.
Jeśli zepsuty jest zasób, który odczytuje główny proces systemu system_server, telefon wpada w pętlę. Proces pada, Android go wznawia, ten znowu czyta ten sam plik i znowu pada. W języku serwisantów to bootloop, czyli pętla restartów. Od instalacji do pierwszej awarii mijała według raportu około sekunda. W jednym zapisie cykl powtórzył się 110 razy, a ekran przez cały czas pokazywał animację uruchamiania.
Błąd nie wykonuje kodu, nie czyta danych i nie daje aplikacji uprawnień. Bitdefender opisuje go jako błąd typu odmowa usługi (DoS), który unieruchamia telefon.
Kogo dotyczy: Android 10 i nowsze, testy na Pixelu 10
Bitdefender odtworzył pętlę na Pixelu 10 z Androidem 17 i poprawkami zabezpieczeń z 5 sierpnia 2026 roku. Firma pisze, że ten sam błąd odtworzyła na starszych wersjach systemu, “starting with Android 10 and above”, czyli od Androida 10 w górę.
Raport nie opisuje testów na telefonach Samsunga, Xiaomi ani innych producentów. Że dotyczy ich ten sam kod Androida, wnioskujemy z opisu błędu, testem nikt tego nie potwierdził. Do chwili publikacji raportu poprawki nie było, więc najnowsza aktualizacja telefonu przed tym błędem nie chroni.
Co odpowiedziało Google
Google zamknęło pierwsze zgłoszenie jako niemożliwe do odtworzenia, a po drugim uznało, że błąd nie zostanie naprawiony w aktualizacji bezpieczeństwa. Bitdefender opisuje przebieg zgłoszeń w programie nagród Google za błędy w Androidzie tak:
- 12 sierpnia 2026 – plik APK zebrany “w obiegu”, bankowy dropper (aplikacja, która doinstalowuje złośliwe oprogramowanie), wywracał emulatory w laboratorium Bitdefendera już przy instalacji;
- 20 sierpnia – pierwsze zgłoszenie do Google, zamknięte ze statusem “Won’t Fix (Not Reproducible)”, czyli “nie naprawimy, nie udało się odtworzyć”, z dopiskiem, że sprawa wykracza poza zakres programu;
- 25 sierpnia – drugie zgłoszenie z działającym dowodem (PoC) i instrukcją odtworzenia; Google odpisało, że to sprawa spoza zakresu poprawki bezpieczeństwa i przekazało ją “odpowiedniemu zespołowi” do rozważenia w przyszłej wersji systemu;
- 5 listopada – publikacja raportu, poprawki nadal brak.
BleepingComputer napisał 5 listopada rano, że zapytał Google o plany naprawy i czeka na odpowiedź. Do godz. 17:15 nie znaleźliśmy publicznego stanowiska Google w tej sprawie.
Bitdefender przypomina, że w 2016 roku Google załatało słabszą wersję podobnego problemu (CVE-2016-6724) i oceniło ją wtedy jako średnio groźną. Według firmy obecne zasady oceny Google traktują pętlę wymagającą resetu jako problem trwały i wysokiej wagi. To interpretacja Bitdefendera, Google się do niej nie odniosło.
Skąd mogłaby przyjść taka aplikacja
Najbardziej oczywiste ryzyko dla użytkownika to plik APK pobrany z linku spoza Sklepu Google Play, choć raport nie ustala, która droga byłaby najbardziej prawdopodobna. Tak wyglądał początek sprawy: próbka, od której Bitdefender zaczął, była bankowym dropperem z obiegu. Jej autor według firmy raczej nie wiedział, że plik coś wywraca, bo zepsuł go program zaciemniający kod.
Raport nie sprawdzał, czy taka aplikacja przeszłaby przez weryfikację w Sklepie Play i przez Google Play Protect. Nie wiadomo więc, czy da się ją tam opublikować. Bitdefender opisuje tylko teoretyczny scenariusz, w którym zepsuty plik trafia do aplikacji dopiero w aktualizacji.
Pozostałe scenariusze z raportu też są hipotetyczne:
- aplikacja, która unieruchamia telefon, mogłaby posłużyć do szantażu: zapłać albo stracisz dane;
- złośliwa aplikacja może zepsuć własną ikonę, przez co ekran główny, lista aplikacji w Ustawieniach i ekran informacji o aplikacji wywracają się przy próbie jej odinstalowania;
- program antywirusowy, który otworzy taki plik, sam pada i nie zdąży go oznaczyć.
Google na stronie pomocy o pobieraniu aplikacji ostrzega, że przy instalowaniu z nieznanych źródeł “urządzenie może zostać uszkodzone, a dane utracone”. Play Protect jest według Google domyślnie włączony i sprawdza także aplikacje spoza Sklepu Play. Stan sprawdzisz w Sklepie Play: ikona profilu, potem Play Protect i Ustawienia, opcja “Skanuj aplikacje za pomocą Play Protect”. Czy Play Protect rozpoznaje takie pliki, Google nie podało.
Bitdefender pisze, że jego program wykrywa takie pliki, ale to produkt autora raportu i według niego samego Android nie pozwala innym aplikacjom zablokować instalacji. Innych sposobów ochrony na samym telefonie firma nie podaje.
Kopia zapasowa Androida: zrób ją, zanim coś się stanie
Kopia zapasowa na koncie Google decyduje o tym, ile stracisz, jeśli telefon trzeba będzie zresetować. Według pomocy Google kopia obejmuje aplikacje i ich dane, historię połączeń, kontakty, ustawienia urządzenia oraz SMS-y i MMS-y. Zdjęcia i filmy chroni osobno Zdjęcia Google. Bezpłatnie konto Google mieści 15 GB.
Ręczna kopia na Androidzie według pomocy Google:
- Otwórz aplikację Ustawienia.
- Kliknij Google (w części telefonów Usługi Google), a potem Wszystkie usługi.
- W sekcji “Tworzenie i przywracanie kopii zapasowej” kliknij Kopia zapasowa.
- Kliknij Utwórz kopię zapasową teraz.
W tym samym miejscu, w sekcji “Szczegóły kopii zapasowej”, zobaczysz, co jest objęte kopią. Google zastrzega, że nie wszystkie aplikacje zapisują w niej wszystkie swoje dane. Czaty WhatsAppa mają własną kopię i trzeba ją włączyć w aplikacji, co opisaliśmy w poradniku o kopii zapasowej WhatsAppa. U Samsunga, Xiaomi i innych producentów nazwy pozycji w Ustawieniach mogą się różnić, a część z nich ma też własną chmurę.
Telefon ciągle się restartuje: co zrobić
Jeśli telefon restartuje się w kółko zaraz po instalacji nowej aplikacji, przy tym błędzie pomaga tylko reset do ustawień fabrycznych. W wąskich warunkach da się jeszcze usunąć plik z komputera przez ADB. Zwykłe porady z pomocy Google nie zadziałają, bo według Bitdefendera system pada w trybie awaryjnym tak samo jak w zwykłym.
Pomoc Google na pętlę restartów każe najpierw uruchomić telefon w trybie awaryjnym, w którym pobrane aplikacje są wyłączone, i usuwać ostatnio zainstalowane aplikacje. Przy innych przyczynach to nadal dobry pierwszy krok. Jak wejść w ten tryb na różnych telefonach, opisaliśmy w tekście o trybie awaryjnym. Bitdefender zarejestrował w trybie awaryjnym 72 kolejne awarie, bo proces systemu czyta plik, zanim tryb awaryjny zacznie działać.
Usunięcie pliku przez ADB
Droga przez ADB (Android Debug Bridge, narzędzie dla programistów) wymaga, żeby debugowanie USB było włączone wcześniej, przed instalacją aplikacji. Komputer musi usunąć plik między kolejnymi awariami. Według Bitdefendera po pierwszym pełnym restarcie telefonu ta metoda też przestaje działać, bo awaria następuje bardzo wcześnie. Dla większości właścicieli telefonów ta droga jest więc zamknięta.
Reset do ustawień fabrycznych krok po kroku
Reset do ustawień fabrycznych według pomocy Google kasuje wszystkie dane z telefonu. Przed resetem przygotuj:
- login i hasło konta Google powiązanego z telefonem (po resecie trzeba je podać);
- kod PIN, wzór albo hasło blokady ekranu;
- telefon naładowany do co najmniej 70% i dostęp do Wi-Fi albo sieci komórkowej, bo reset może potrwać nawet godzinę.
Gdy telefon nie dochodzi do Ustawień, Google odsyła do resetu przyciskami zasilania i głośności według instrukcji producenta. Na Pixelu jest do tego tryb Fastboot. Ogólne zasady resetu telefonu i laptopa zebraliśmy w tekście o przywracaniu ustawień fabrycznych.
Pixel 4a i nowsze mają też narzędzie Google “Aktualizacja i naprawa oprogramowania” (pixelrepair.withgoogle.com), które instaluje system od nowa przez kabel USB. Bitdefender nie pisze, czy wyprowadza ono z tej pętli, i tego nie sprawdzaliśmy.
Po resecie przywracaj dane z kopii, ale nie instaluj ponownie podejrzanej aplikacji. Pomoc Google ostrzega: “Jeśli przyczyną problemu była pobrana aplikacja i zostanie ona ponownie zainstalowana, problem może powrócić”.
Czy ten błąd kradnie dane z telefonu?
Nie. Według Bitdefendera błąd nie wykonuje kodu, nie odczytuje danych i nie daje aplikacji uprawnień. Dane traci się dopiero przez reset, jeśli nie ma kopii zapasowej. Ten sam tydzień przyniósł drugi błąd Androida, który odcina telefon od sieci, czyli SMS of Death. Na tamten Google wydało poprawkę w listopadowej aktualizacji.
Podsumowanie
GhostMap to błąd Androida 10 i nowszych opisany 5 listopada 2026 roku przez Bitdefender Labs. Spreparowana aplikacja bez kodu i bez uprawnień po samej instalacji wpędza telefon w pętlę restartów, w której nie pomaga ani zwykły restart, ani tryb awaryjny. Wyjściem jest reset do ustawień fabrycznych, a ADB działa tylko przy wcześniej włączonym debugowaniu USB. Pierwsze zgłoszenie z 20 sierpnia Google zamknęło. Po drugim z 25 sierpnia uznało, że nie naprawi błędu w aktualizacji bezpieczeństwa, i przekazało go zespołowi od funkcji. Najnowsza aktualizacja przed tym więc nie chroni. Ataków z tą techniką Bitdefender nie widział, a raport opisuje testy tylko na Pixelu 10. Zrób dziś ręczną kopię zapasową w Ustawieniach, sprawdź, czy Play Protect skanuje aplikacje, i nie instaluj plików APK z linków w SMS-ach i wiadomościach.
