CVE-2026-10702: RCE w Firefoxie po wejściu na stronę

29 lipca 2026 roku opublikowano nowe, szczegółowe omówienie wpływu CVE-2026-10702 na Firefox i przeglądarkę Tor. To luka typu JIT miscompilation w silniku JavaScript SpiderMonkey. Mozilla załatała ją już 2 czerwca w Firefoxie 151.0.3 i oceniła wpływ jako wysoki. Nowa analiza pokazuje jednak, dlaczego samo odwiedzenie złośliwej strony może wystarczyć do uzyskania wykonania kodu w procesie renderującym oraz jak badacze wykorzystali tę lukę jako pierwszy etap szerszego łańcucha na Androidzie 17.

Najważniejsze zastrzeżenie: publiczne źródła nie potwierdzają wykorzystania przeciw użytkownikom w realnych atakach. Udostępniony łańcuch end-to-end dotyczy konkretnego wspieranego buildu urządzenia ARM64 z Androidem 17. Nie jest dowodem, że każda instalacja Firefoksa, Tora lub Androida może zostać automatycznie przejęta identycznym kodem.

Co wiadomo na pewno

Mozilla Foundation Security Advisory 2026-54 potwierdza, że CVE-2026-10702 to błędna kompilacja JIT w komponencie JavaScript Engine: JIT, zgłoszona przez Nebula Security i naprawiona w Firefoxie 151.0.3. Producent oznaczył wpływ jako wysoki.

Opublikowane 29 lipca omówienie The Hacker News, oparte na technicznej analizie Nebula Security, dodaje:

wejście na stronę z odpowiednio przygotowanym JavaScriptem może uruchomić błąd bez dodatkowego kliknięcia;
pierwszy etap daje wykonanie kodu w procesie renderującym przeglądarki, nadal wewnątrz sandboxa;
publiczny materiał wykorzystuje CVE-2026-10702 jako wejście do łańcucha IonStack;
drugi etap to osobna luka jądra Linux, CVE-2026-43499, nazwana GhostLock;
pokazany łańcuch prowadzi do roota na jednym wspieranym buildzie ARM64 Androida 17;
badacze udostępnili materiał PoC, co skraca czas potrzebny innym osobom do zrozumienia błędu.

Raportowanie wskazuje, że wadliwa zmiana była obecna w stabilnych wydaniach od Firefoksa 147 do 151.0.2. Oficjalny biuletyn Mozilli formułuje zalecenie przez wersję naprawioną, dlatego administrator powinien opierać politykę na 151.0.3 lub nowszej, a nie samodzielnie wnioskować o bezpieczeństwie starszych gałęzi.

Jak błąd JIT zamienia optymalizację w use-after-free

Silnik JavaScript może interpretować kod instrukcja po instrukcji, ale często wykonywane funkcje kompiluje JIT do kodu maszynowego. Aby przyspieszyć program, kompilator usuwa powtarzające się odczyty, upraszcza obiekty i zakłada, że określone operacje tylko czytają pamięć.

Problem dotyczył operacji MObjectToIterator wykonywanej z ustawieniem skipRegistration. Kompilator oznaczał ją jak odczyt pól obiektu. W rzeczywistości rozwiązanie leniwej właściwości mogło zaalokować nowy bufor dynamicznych slotów i zwolnić stary. Global value numbering uznawał późniejszy odczyt bufora za redundantny i ponownie używał nieaktualnego wskaźnika.

W uproszczeniu:

JIT zapamiętuje wskaźnik do bufora właściwości obiektu;
operacja uznana za „tylko odczyt” może jednak zmienić obiekt i zwolnić ten bufor;
optymalizator nie widzi mutacji, więc zachowuje stary wskaźnik;
atakujący wypełnia zwolnioną pamięć kontrolowanymi danymi;
późniejszy kod używa wskaźnika prowadzącego do nowej, kontrolowanej zawartości.

To nie jest zwykły błąd składni JavaScript. Naruszone zostało założenie kompilatora o efektach ubocznych operacji. Optymalizacja była logicznie poprawna wyłącznie przy błędnym kontrakcie aliasowania.

Co daje pierwszy etap, a czego nie daje

PoC odzyskuje wskaźnik typu/shape, buduje fałszywy obiekt i doprowadza do dowolnego odczytu oraz zapisu pamięci przez kontrolę nad Uint8Array. Następnie może zmienić ochronę pamięci i skierować wejście funkcji WebAssembly do kodu maszynowego.

To brzmi jak pełne przejęcie, ale proces renderujący nadal jest oddzielony sandboxem. Nowoczesna przeglądarka zakłada, że parser lub silnik JS może mieć błędy i ogranicza dostęp renderera do systemu. Dlatego atak potrzebuje drugiej podatności lub błędu konfiguracji, aby wyjść poza proces i uzyskać uprawnienia systemowe.

Rozróżnienie jest ważne operacyjnie:

CVE-2026-10702 daje wejście przez treść WWW;
sandbox ogranicza zasięg pierwszego etapu;
CVE-2026-43499 stanowi w pokazanym łańcuchu osobną eskalację w jądrze;
poprawka Firefoksa blokuje opisany punkt wejścia, ale nie naprawia luki jądra.

Dlaczego pojawia się przeglądarka Tor

Tor Browser bazuje na Firefoxie ESR i dziedziczy dużą część jego silnika. Badacze wskazali, że błąd dotyczył również wydań Tora zawierających podatny kod, ale publiczne źródła nie wskazują kompletnej listy numerów wersji Tor Browser. Nie należy więc tworzyć własnej macierzy na podstawie numeru zwykłego Firefoksa.

Użytkownik Tora powinien zainstalować najnowsze wydanie dostarczone przez Tor Project i zweryfikować, że automatyczna aktualizacja zakończyła się sukcesem. Organizacja, która dystrybuuje Tor w środowisku badawczym lub dziennikarskim, powinna zarządzać nim jak osobnym produktem, nie jak aliasem „Firefox ESR”.

Atak na użytkownika Tora ma szczególny wymiar: nawet ograniczone wykonanie kodu w przeglądarce może zagrozić danym sesji i anonimowości, a pełny łańcuch systemowy — identyfikacji urządzenia. To nie znaczy, że sieć Tor została złamana. Problem leży w aplikacji końcowej i systemie urządzenia.

Wersje, aktualizacje i pytania do inwentarza

Minimalnym stanem dla zwykłego Firefoksa jest 151.0.3 lub nowszy. W polityce firmowej nie wystarczy sprawdzić, czy auto-update jest włączony. Trzeba odczytać wersję efektywną na:

laptopach stacjonarnych i zdalnych;
VDI i złotych obrazach;
maszynach uprzywilejowanych administratorów;
środowiskach testowych z wyłączonym update’em;
przeglądarkach przenośnych i kontenerach;
systemach, które wracają po dłuższym wyłączeniu.

Jeżeli organizacja używa Firefoksa ESR, powinna odczytać biuletyny właściwe dla tej gałęzi. MFSA2026-54 nie wymienia ESR jako produktu dotkniętego. Nie należy automatycznie uznawać dowolnego ESR za podatny ani bezpieczny bez sprawdzenia źródła.

Publiczny PoC zmienia pilność, nie dowodzi ataków

Kod demonstracyjny pozwala niezależnie odtworzyć mechanizm na opisanym środowisku. Zwiększa to dostępność wiedzy ofensywnej, lecz nie jest dowodem aktywnej kampanii. Dla obrony oznacza trzy rzeczy:

termin aktualizacji powinien być liczony w godzinach lub dniach, nie w kwartale;
skan wersji trzeba połączyć z kontrolą jądra i urządzeń mobilnych;
SOC powinien zachować telemetrię przeglądarki i hosta z okresu ekspozycji.

Nie zalecamy uruchamiania publicznego exploita na komputerach produkcyjnych. Wystarczającym dowodem naprawy jest wersja, integralność pakietu i bezpieczny test polityki aktualizacji. Pełne odtworzenie powinno odbywać się tylko w odizolowanym laboratorium i w ramach uzgodnionego zakresu.

Hipotezy detekcyjne

Eksploatacja JIT jest trudna do wykrycia wyłącznie w logu HTTP. Warto połączyć kilka warstw:

awarie Firefoksa lub procesu content po wejściu na nową domenę;
nietypowe zdarzenia WebAssembly oraz nagłe zmiany ochrony pamięci widoczne dla EDR;
proces potomny, dostęp do urządzenia lub wywołania jądra nietypowe dla renderera;
pobranie kolejnego ładunku lub połączenie sieciowe z procesu przeglądarki;
wyłączenie aktualizacji albo powrót wersji 151.0.2 w VDI;
sekwencję: odwiedziny strony → crash/alert pamięci → eskalacja → nowy proces jako root.

Nie są to sygnatury producenta. Brak alertu nie wyklucza wykorzystania, zwłaszcza na urządzeniu bez EDR. Jeżeli użytkownik wysokiego ryzyka działał na podatnym buildzie i odwiedzał nieznane strony, zespół powinien rozważyć analizę urządzenia szerszą niż sam update.

Co zrobić dzisiaj

Administratorzy powinni wymusić Firefox 151.0.3 lub nowszy, zrestartować przeglądarkę po aktualizacji i usunąć podatne obrazy z katalogów VDI. Użytkownicy Tor Browser powinni użyć mechanizmu aktualizacji Tor Project i sprawdzić aktualny numer wersji. Urządzenia Android objęte zarządzaniem wymagają osobnej kontroli poziomu poprawek jądra, ponieważ update przeglądarki nie usuwa CVE-2026-43499.

Następnie warto zweryfikować, czy polityka aktualizacji nie może być wyłączona przez zwykłego użytkownika, czy telemetria obejmuje urządzenia poza biurem i jak szybko organizacja potrafi wymusić restart. To praktyczny temat dla szkolenia zespołów IT i pracowników: komunikat „zaktualizuj przeglądarkę” musi wyjaśniać potrzebę ponownego uruchomienia i nie może prowadzić do fałszywych instalatorów.

Przy przeglądzie warto połączyć wersje z procesem zarządzania podatnościami oraz audytem bezpieczeństwa IT, który sprawdzi wymuszanie konfiguracji, pokrycie urządzeń i reakcję na publiczny PoC.

Źródła i granice

Faktem producenta jest luka JIT o wysokim wpływie naprawiona w Firefoxie 151.0.3, opisana w MFSA2026-54. Szczegóły przyczyny i łańcucha pochodzą z Nebula Security i zostały zebrane w publikacji z 29 lipca przez The Hacker News.

Nie ma potwierdzenia wykorzystania w atakach na użytkowników. Zakres wersji Tor Browser nie został publicznie precyzyjnie wyliczony, a pełny PoC systemowy dotyczy konkretnego buildu Androida 17. Hipotezy detekcyjne i plan operacyjny są wnioskami BreachRoad. Najważniejszy fakt pozostaje prosty: wejście przez przeglądarkę zostało załatane, ale tylko tam, gdzie aktualizacja rzeczywiście działa.

Dlaczego publiczny PoC zmienia priorytet, ale nie dowodzi ataku

Publiczna demonstracja zmniejsza koszt analizy dla kolejnych badaczy i potencjalnych napastników. Nie jest jednak telemetrią z kampanii. Organizacja powinna podnieść pilność aktualizacji, jednocześnie zachowując poprawny język raportowania: „dostępny PoC i brak potwierdzonego wykorzystania” zamiast „atak trwa”.

SOC nie powinien próbować wykrywać wyłącznie jednej strony demonstracyjnej. Eksploatacja błędu JIT może prowadzić do awarii procesu treści, nietypowej sekwencji alokacji pamięci lub uruchomienia kolejnego etapu, lecz normalna przeglądarka generuje dużo szumu. Najbardziej wiarygodna korelacja łączy podatną wersję, wejście na rzadką domenę, awarię procesu i kolejne zachowanie na urządzeniu.

W środowisku o ograniczonej telemetrii najskuteczniejszą kontrolą pozostaje usunięcie podatnej wersji. Detekcja nie może stać się wymówką dla opóźnienia poprawki. Zespół może za to użyć incydentu do rozwinięcia detection engineering w SIEM i przeglądu danych zbieranych z przeglądarek.

Firefox, Tor Browser i Android to trzy osobne inwentarze

Organizacje często raportują jedną pozycję „Firefox”, choć mają wersję desktopową, ESR, przenośne instalacje, obrazy VDI i Tor Browser. Każdy kanał ma osobny mechanizm wydawania i powinien być sprawdzony niezależnie. Dla Tor Browser bezpiecznym źródłem numeru wersji jest sam Tor Project; mechaniczne przenoszenie numeracji Firefoksa może prowadzić do błędnego wniosku.

Android dodaje kolejną granicę odpowiedzialności. Poprawka przeglądarki usuwa etap dotyczący silnika, lecz opisany przez badaczy etap jądra wymaga odpowiedniego buildu systemu. Administrator powinien zebrać model urządzenia, wersję systemu, poziom poprawek, kanał dystrybucji i status wsparcia producenta. Urządzenie bez aktualizacji może wymagać ograniczenia dostępu do wrażliwych usług.

Jak zamknąć incydent operacyjnie

Raport powinien pokazać pokrycie: ile urządzeń ma wersję naprawioną, ile czeka na restart, ile jest poza zarządzaniem i ile nie raportuje stanu. Następnie zespół ustala właścicieli wyjątków i termin. Cyber Threat Intelligence pomaga oddzielić dostępność PoC od dowodu kampanii, a Akademia Breachroad daje pracownikom bezpieczne podstawy higieny aktualizacji.

Zamknięcie powinno wymagać nie tylko zainstalowanego pakietu, ale też ponownego uruchomienia procesu i usunięcia starych obrazów. Inaczej podatna wersja wróci przy kolejnym logowaniu do VDI lub odtworzeniu urządzenia.