Google łata szósty zero-day Chrome w 2026 roku. Luka była już wykorzystywana w realnych atakach

Google po raz kolejny w tym roku musi reagować na lukę bezpieczeństwa Chrome, zanim użytkownicy zdążą spokojnie zainstalować poprawkę. Najnowszy problem otrzymał oznaczenie CVE-2026-85046 i dotyczy silnika V8, czyli jednego z najważniejszych elementów przeglądarki odpowiedzialnych za wykonywanie JavaScriptu oraz WebAssembly. Google potwierdziło, że exploit wykorzystujący podatność istnieje już "in the wild", co w praktyce oznacza zaobserwowanie rzeczywistego wykorzystania poza kontrolowanym laboratorium. Firma nie podała jednak, kto prowadzi ataki, ilu użytkowników zostało zaatakowanych ani jakie strony lub kampanie były wykorzystywane do dostarczenia exploita.

To już szósty zero-day Chrome załatany przez Google w 2026 roku. Sama liczba nie oznacza, że przeglądarka nagle stała się niebezpieczna, ale dobrze pokazuje skalę zainteresowania, jakim Chrome cieszy się wśród badaczy bezpieczeństwa i profesjonalnych grup atakujących. Przeglądarka jest dziś jednym z najważniejszych programów na komputerze. Obsługuje bankowość, pocztę, narzędzia firmowe, dokumenty w chmurze i dziesiątki zalogowanych sesji. Luka pozwalająca przejąć kontrolę nad procesem renderującym może być więc wyjątkowo wartościowym pierwszym etapem bardziej złożonego ataku. Najważniejszą reakcją użytkownika jest w tej sytuacji bardzo prosta czynność - aktualizacja i ponowne uruchomienie Chrome.

Czym jest CVE-2026-85046 i dlaczego Google uznało tę lukę Chrome za poważną?

CVE-2026-85046 to błąd typu confusion w V8. Najprościej mówiąc, oprogramowanie w określonych okolicznościach może potraktować dane tak, jakby były innym typem obiektu, niż są w rzeczywistości. W językach i silnikach wykorzystujących dynamiczne struktury pamięci taki błąd może doprowadzić do nieprawidłowego odczytu lub zapisu danych w pamięci. W przypadku przeglądarki konsekwencje mogą być znacznie poważniejsze niż zwykłe zamknięcie karty. Odpowiednio przygotowany exploit może wykorzystać zaburzoną strukturę pamięci do wykonania operacji, których normalna strona internetowa nie powinna mieć możliwości wykonywać.

Google sklasyfikowało CVE-2026-85046 jako podatność wysokiego ryzyka. Według publicznie dostępnych opisów atak może zostać dostarczony za pomocą odpowiednio przygotowanej zawartości HTML i umożliwić wykonanie dowolnego kodu wewnątrz sandboxa renderera. To ważne rozróżnienie. Nie oznacza automatycznie pełnego przejęcia całego systemu operacyjnego po jednym kliknięciu. Chrome stosuje izolację procesów właśnie po to, aby ograniczyć skutki kompromitacji jednej strony. W zaawansowanych kampaniach luka w V8 może być jednak łączona z drugą podatnością pozwalającą wydostać się z sandboxa i zwiększyć zakres kontroli nad urządzeniem.

Co oznacza informacja, że exploit dla Chrome był już wykorzystywany w realnych atakach?

Określenie "exploited in the wild" jest znacznie poważniejsze niż informacja o zwykłym znalezieniu podatności przez badacza. Wiele luk zostaje odkrytych podczas audytów, konkursów bezpieczeństwa lub automatycznego testowania, zanim ktokolwiek wykorzysta je przeciwko użytkownikom. W przypadku CVE-2026-85046 Google wie, że exploit funkcjonował już poza środowiskiem testowym. Oznacza to, że przynajmniej jeden podmiot posiadał praktyczną metodę wykorzystania błędu jeszcze zanim większość użytkowników otrzymała aktualizację.

Nie wiadomo natomiast, jak szeroka była kampania. Google celowo ogranicza obecnie szczegóły techniczne. To standardowa praktyka, gdy duża część użytkowników nie zdążyła jeszcze zainstalować poprawki. Opublikowanie kompletnego opisu błędu i przykładowego kodu exploita zbyt wcześnie ułatwiłoby innym grupom odtworzenie ataku. Brak informacji o ofiarach nie powinien być więc interpretowany jako dowód, że kampania była masowa lub przeciwnie - że dotyczyła tylko kilku osób. Na tym etapie wiadomo jedynie, że exploit rzeczywiście działał i został zauważony poza laboratorium.

Dlaczego luka w silniku V8 jest szczególnie niebezpieczna dla użytkowników Chrome?

V8 odpowiada za wykonywanie JavaScriptu, który jest podstawowym elementem współczesnego internetu. Skrypty uruchamiają się praktycznie na każdej bardziej rozbudowanej stronie - w aplikacjach internetowych, sklepach, systemach pocztowych, komunikatorach czy serwisach społecznościowych. To oznacza ogromną powierzchnię ataku. Jeśli przestępca potrafi przygotować stronę wykorzystującą błąd w V8, ofiara nie musi instalować klasycznego programu z nieznanego źródła. W niektórych scenariuszach wystarczy doprowadzić ją do otwarcia odpowiednio spreparowanej strony.

V8 jest również niezwykle skomplikowanym komponentem. Aby JavaScript działał szybko, silnik stosuje zaawansowaną kompilację w czasie rzeczywistym, optymalizację kodu i wiele mechanizmów zarządzania pamięcią. Ta złożoność zwiększa wydajność, ale tworzy również potencjalne miejsca powstawania subtelnych błędów. Z punktu widzenia atakującego podatności w silnikach JavaScript są szczególnie wartościowe, ponieważ mogą być dostępne z poziomu zwykłej treści internetowej. Dlatego V8 od lat pozostaje jednym z najważniejszych celów zarówno badaczy bezpieczeństwa, jak i twórców zaawansowanych exploitów.

Na czym dokładnie polega błąd type confusion w Google Chrome?

Program komputerowy musi wiedzieć, jak interpretować dane znajdujące się w pamięci. Liczba, tekst, tablica czy obiekt posiadają określoną strukturę. Type confusion pojawia się wtedy, gdy program z powodu błędu zaczyna traktować jeden rodzaj danych jak inny. Samo pomieszanie typów brzmi niewinnie, ale przy odpowiednim ułożeniu pamięci może spowodować, że program zacznie odczytywać fragmenty, do których nie powinien mieć dostępu, albo zapisywać informacje pod niewłaściwymi adresami.

W przypadku CVE-2026-85046 badacz opisujący techniczną przyczynę wskazał na problem w kompilatorach V8 związany z nieprawidłowym przypisaniem mapy dla tablicy. To mogło prowadzić do możliwości arbitralnego odczytu i zapisu w stercie JavaScriptu. Dla przeciętnego użytkownika szczegóły implementacyjne nie są najważniejsze. Kluczowe jest to, że błąd pamięci może zostać zamieniony w element exploita pozwalającego wykonywać operacje poza normalnymi ograniczeniami strony. To właśnie dlatego tego rodzaju podatności otrzymują wysoki priorytet i są naprawiane natychmiast po potwierdzeniu aktywnego wykorzystania.

Czy samo wejście na złośliwą stronę może wystarczyć do wykorzystania luki Chrome?

Potencjalny scenariusz ataku zakłada wykorzystanie odpowiednio przygotowanej treści internetowej, dlatego wejście na stronę kontrolowaną przez przestępcę może stanowić pierwszy krok. Nie oznacza to jednak, że każda witryna może automatycznie przejąć nieaktualnego Chrome ani że exploit działa na każdej konfiguracji. Atakujący musi wykorzystać konkretny błąd i dostosować kod do wersji przeglądarki oraz mechanizmów ochronnych. W zaawansowanych kampaniach ofiara może zostać skierowana na złośliwą stronę poprzez phishing, reklamę, przejętą witrynę albo specjalnie przygotowany link.

Szczególnie niebezpieczne są tak zwane watering hole attacks, w których atakujący nie kontaktuje się bezpośrednio z ofiarą, lecz infekuje lub podstawia stronę, którą wybrana grupa regularnie odwiedza. Wtedy wejście na pozornie znajomą witrynę może uruchomić kod sprawdzający wersję przeglądarki i próbujący wykorzystać podatność. Google nie ujawniło jednak, czy właśnie taki mechanizm był używany w przypadku CVE-2026-85046. Nie należy więc przedstawiać konkretnego scenariusza jako potwierdzonego sposobu prowadzenia obecnych ataków.

Czy wykorzystanie CVE-2026-85046 oznacza pełne przejęcie komputera?

Nie musi. Chrome od wielu lat wykorzystuje sandboxing, który ogranicza uprawnienia procesu odpowiedzialnego za wyświetlanie strony. Jeśli atakujący przejmie kontrolę nad rendererem, nadal znajduje się w środowisku zaprojektowanym tak, aby nie pozwalało mu swobodnie odczytywać całego dysku, instalować programów czy przejmować systemu operacyjnego. To jedna z najważniejszych warstw obrony nowoczesnych przeglądarek i powód, dla którego pojedyncza luka często nie wystarcza do pełnej kompromitacji urządzenia.

Najbardziej zaawansowane ataki wykorzystują dlatego łańcuch kilku podatności. Pierwsza może pozwolić na wykonanie kodu w procesie przeglądarki, a kolejna na ucieczkę z sandboxa lub podniesienie uprawnień. Takie zestawy exploitów są znacznie trudniejsze i droższe do przygotowania, dlatego często pojawiają się w kampaniach ukierunkowanych na szczególnie wartościowe cele. Google nie ujawniło, czy CVE-2026-85046 było wykorzystywane samodzielnie, czy stanowiło element większego łańcucha. Na obecnym etapie nie należy więc dopowiadać szczegółów, których producent nie potwierdził.

Która wersja Chrome usuwa najnowszy zero-day CVE-2026-85046?

Dla komputerów z systemem Windows i macOS poprawka została udostępniona w Chrome 152.0.7977.82/.83. Użytkownicy Linux otrzymują wersję 152.0.7977.82. Aktualizacja rozpoczęła się 3 września 2026 roku i jest stopniowo udostępniana wszystkim użytkownikom. Wersja Chrome na Androida o numerze 152.0.7977.82 również zawiera odpowiadające poprawki bezpieczeństwa. Sam fakt posiadania Chrome 152 nie wystarcza więc do stwierdzenia, że urządzenie jest bezpieczne - znaczenie ma pełny numer kompilacji.

Najłatwiej sprawdzić go bezpośrednio w przeglądarce. Na komputerze należy otworzyć menu Chrome, przejść do sekcji Pomoc i wybrać informacje o Google Chrome. Przeglądarka automatycznie sprawdzi wtedy dostępność aktualizacji i rozpocznie instalację, jeśli nowsza wersja jest dostępna. Bardzo ważne jest późniejsze ponowne uruchomienie programu. Aktualizacja pobrana na dysk nie chroni aktywnych procesów starej wersji, dopóki Chrome nie zostanie zamknięty i uruchomiony ponownie.

Dlaczego nie wystarczy poczekać, aż Chrome sam się zaktualizuje?

Chrome posiada automatyczne aktualizacje i dla większości użytkowników jest to bardzo skuteczny mechanizm. Problem polega na tym, że instalacja nie zawsze następuje natychmiast po udostępnieniu poprawki. Google rozprowadza nowe wersje stopniowo, a użytkownik może mieć przeglądarkę otwartą przez wiele dni. W takim przypadku pliki aktualizacji mogą być już pobrane, ale działający proces Chrome nadal korzysta ze starego kodu. Dlatego przy aktywnie wykorzystywanym zero-day ręczne sprawdzenie wersji jest rozsądnym działaniem.

W firmach sytuacja może być jeszcze bardziej złożona. Organizacje często kontrolują wersje przeglądarek centralnie i opóźniają wdrożenia, aby wcześniej sprawdzić kompatybilność z wewnętrznymi aplikacjami. Przy zwykłej aktualizacji takie podejście ma sens, ale w przypadku potwierdzonego aktywnego wykorzystania czas reakcji staje się znacznie ważniejszy. Zespoły bezpieczeństwa powinny więc wiedzieć nie tylko, czy aktualizacja została udostępniona, ale również jaki procent urządzeń faktycznie został już zrestartowany i pracuje na poprawionej wersji.

Czy Microsoft Edge, Brave, Opera i Vivaldi również mogą być narażone na tę lukę?

Wiele popularnych przeglądarek wykorzystuje Chromium, czyli otwartą bazę technologiczną, na której zbudowany jest również Chrome. Microsoft Edge, Brave, Opera czy Vivaldi korzystają z dużej części tego samego kodu, w tym z silnika V8. Jeśli podatność znajduje się we wspólnym komponencie Chromium, może potencjalnie dotyczyć również innych przeglądarek opartych na tym projekcie. Nie oznacza to jednak, że numery wersji oraz terminy poprawek będą identyczne.

Każdy producent musi włączyć odpowiednią poprawkę do własnej wersji i udostępnić aktualizację użytkownikom. Dlatego osoby korzystające z przeglądarek chromiumowych również powinny sprawdzić, czy posiadają najnowszą wersję. Nie należy zakładać, że używanie Edge lub Brave automatycznie eliminuje ryzyko związane z błędem V8. Z drugiej strony użytkownik Firefoxa czy Safari korzysta z innych silników JavaScript i CVE-2026-85046 nie odnosi się bezpośrednio do tych przeglądarek. Mają one jednak własne podatności i również powinny być regularnie aktualizowane.

Dlaczego Google nie publikuje teraz wszystkich technicznych szczegółów podatności?

W świecie bezpieczeństwa istnieje ważny okres pomiędzy wydaniem poprawki a jej zainstalowaniem przez większość użytkowników. Gdyby Google w tym momencie opublikowało szczegółowy opis błędu, instrukcję wykorzystania i fragmenty kodu, cyberprzestępcy mogliby analizować materiał i szybko tworzyć własne exploity. Użytkownicy, którzy nie otrzymali jeszcze aktualizacji albo nie uruchomili ponownie przeglądarki, staliby się wtedy łatwiejszym celem.

Dlatego dostęp do zgłoszenia błędu może pozostać ograniczony, dopóki odpowiednio duża część użytkowników nie zostanie zabezpieczona. Jest to standardowa polityka projektu Chromium. Ograniczenia mogą trwać jeszcze dłużej, jeśli problem znajduje się w bibliotece używanej również przez inne projekty, które nie zdążyły wdrożyć poprawki. Po pewnym czasie szczegóły zazwyczaj stają się publiczne i badacze mogą dokładnie przeanalizować podatność. Z punktu widzenia bezpieczeństwa priorytetem jest jednak najpierw zmniejszenie liczby urządzeń podatnych na gotowy exploit.

Kto odkrył najnowszą lukę zero-day w Google Chrome?

CVE-2026-85046 zostało zgłoszone Google 4 sierpnia 2026 roku przez badacza Salvatore Gulizię, posługującego się również pseudonimem Serotav. Google przyznało za zgłoszenie nagrodę w wysokości 1000 dolarów. Sama wysokość nagrody nie jest prostym wskaźnikiem tego, jak groźny jest później exploit. Programy bug bounty uwzględniają wiele czynników, między innymi jakość zgłoszenia, zakres podatności oraz to, jakie elementy exploita zostały dostarczone badaczom producenta.

Interesujące jest to, że luka została zgłoszona około miesiąc przed opublikowaniem poprawki, a później Google potwierdziło istnienie exploita działającego w realnym świecie. Nie oznacza to automatycznie, że osoba zgłaszająca podatność miała związek z atakami. Badacze bezpieczeństwa bardzo często niezależnie odnajdują błędy, które równolegle odkryły inne grupy. Szczegóły dotyczące sposobu, w jaki Google dowiedziało się o aktywnym wykorzystaniu CVE-2026-85046, nie zostały obecnie publicznie ujawnione.

Dlaczego CVE-2026-85046 jest już szóstym zero-day Chrome w 2026 roku?

Wcześniej Google informowało o aktywnym wykorzystaniu pięciu innych podatności: CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281 oraz CVE-2026-11645. Dotyczyły różnych części przeglądarki, między innymi CSS, Skia, V8 oraz Dawn. Szczególnie interesujący był marzec, kiedy w krótkim odstępie naprawiono dwa aktywnie wykorzystywane błędy wykryte przez Google Threat Analysis Group, zespół zajmujący się między innymi analizą wysoce zaawansowanych kampanii.

Sześć zero-dayów w jednym roku może wyglądać alarmująco, ale liczby trzeba interpretować ostrożnie. Chrome jest jedną z najpopularniejszych aplikacji na świecie, dlatego jest wyjątkowo atrakcyjnym celem. Jednocześnie Google prowadzi rozbudowane programy bug bounty, wykorzystuje własne zespoły badawcze i automatyczne narzędzia wykrywające błędy pamięci. Duża liczba poprawek może więc świadczyć jednocześnie o dużej powierzchni ataku i o intensywności procesu wykrywania podatności. Dla użytkownika najważniejszy wniosek pozostaje niezmienny - przeglądarka jest oprogramowaniem, które powinno aktualizować się możliwie szybko.

Czy sześć zero-dayów oznacza, że Google Chrome jest mniej bezpieczny niż inne przeglądarki?

Nie można wyciągnąć takiego wniosku wyłącznie na podstawie liczby wykrytych zero-dayów. Porównanie bezpieczeństwa przeglądarek jest znacznie bardziej skomplikowane. Trzeba uwzględnić liczbę użytkowników, atrakcyjność produktu dla atakujących, szybkość publikowania poprawek, architekturę sandboxa, izolację witryn, system aktualizacji oraz skuteczność wykrywania podatności. Produkt, w którym publicznie ujawnia się więcej błędów, nie musi automatycznie być mniej bezpieczny od programu, w którym mniej problemów zostaje odkrytych lub opisanych.

Chrome ma jednocześnie cechę, która czyni go wyjątkowo wartościowym celem. Ogromny udział w rynku powoduje, że pojedynczy exploit może potencjalnie działać na bardzo dużej liczbie urządzeń. Zaawansowane grupy atakujące mogą z kolei wykorzystywać tę przeglądarkę przeciwko konkretnym osobom, ponieważ istnieje duże prawdopodobieństwo, że cel korzysta właśnie z Chromium. Dlatego pytanie nie powinno brzmieć wyłącznie "która przeglądarka ma mniej CVE?", ale również "jak szybko producent reaguje, jak skutecznie izoluje exploit i jak szybko użytkownicy otrzymują poprawkę?".

Czy antywirus ochroni użytkownika przed zero-dayem Chrome?

Może pomóc, ale nie zastępuje aktualizacji. Program antywirusowy, EDR lub inne narzędzie ochronne może rozpoznać część kolejnych etapów ataku, na przykład uruchamianie podejrzanego procesu, pobieranie złośliwego pliku czy próbę modyfikacji systemu. Może także blokować znane domeny wykorzystywane w kampanii. Problem polega na tym, że zero-day z definicji wykorzystuje wcześniej niezałatany błąd, a sam exploit może być przygotowany w sposób, którego klasyczne mechanizmy sygnaturowe jeszcze nie znają.

Najważniejszą warstwą ochrony jest usunięcie podatności z samej aplikacji. Po zainstalowaniu poprawionej wersji kod wykorzystujący konkretny błąd powinien przestać działać zgodnie z zamiarem atakującego. Antywirus pozostaje kolejną warstwą zabezpieczenia, szczególnie jeśli exploit jest częścią większego łańcucha prowadzącego do instalacji malware. Najgorszym podejściem jest natomiast pozostawianie starej wersji przeglądarki z założeniem, że inny program bezpieczeństwa przejmie całą odpowiedzialność.

Czy tryb incognito chroni przed wykorzystaniem luki zero-day w Chrome?

Nie. Tryb incognito jest przede wszystkim funkcją prywatności lokalnej. Ogranicza zapisywanie historii przeglądania i usuwa część danych sesji po zamknięciu okna, ale nadal korzysta z tego samego silnika przeglądarki. Jeżeli podatność znajduje się w V8, otwarcie złośliwej strony w trybie incognito nie sprawia, że silnik JavaScript przestaje być podatny. To częste nieporozumienie wynikające z traktowania incognito jak trybu zwiększonego bezpieczeństwa.

Podobnie VPN nie naprawi podatności w Chrome. Może zaszyfrować część ruchu pomiędzy urządzeniem a serwerem VPN i ukryć publiczny adres IP przed odwiedzaną stroną, ale strona nadal może dostarczyć JavaScript do przeglądarki. Rozszerzenie blokujące reklamy może natomiast zmniejszyć ekspozycję na niektóre złośliwe reklamy, lecz również nie jest pełnym rozwiązaniem. Przy aktywnym zero-dayu najważniejsza jest poprawiona wersja aplikacji, a pozostałe środki bezpieczeństwa pełnią funkcję dodatkowych warstw ochrony.

Czy zwykły użytkownik powinien obawiać się, że był celem tej kampanii?

Na podstawie publicznych informacji nie można obecnie określić skali ataków. Google nie podało, czy exploit był wykorzystywany masowo, czy przeciwko wąskiej grupie wybranych celów. Wiele zaawansowanych zero-dayów przeglądarek pojawia się początkowo w operacjach ukierunkowanych, ponieważ działający exploit ma ogromną wartość i jego twórcy nie chcą zbyt szybko ujawniać go poprzez masowe wykorzystanie. Nie można jednak zakładać, że dokładnie tak wyglądała ta kampania bez dodatkowych danych.

Dla przeciętnej osoby właściwa reakcja jest więc proporcjonalna: nie ma potrzeby panikować ani przestać korzystać z internetu, ale należy natychmiast sprawdzić aktualizację. Osoby szczególnie narażone na ukierunkowane cyberataki - administratorzy, dziennikarze, pracownicy organizacji strategicznych, politycy, osoby posiadające dostęp do wartościowych danych czy kadra kierownicza - powinny traktować takie komunikaty jeszcze poważniej. W ich przypadku szybkie patchowanie oraz dodatkowe zabezpieczenia urządzeń mają szczególne znaczenie.

Co powinna zrobić firma, jeśli pracownicy korzystają z Google Chrome?

Pierwszym krokiem powinno być sprawdzenie wersji Chrome na wszystkich zarządzanych komputerach. Samo poleganie na informacjach, że automatyczne aktualizacje są włączone, może być niewystarczające. Administrator powinien wiedzieć, ile urządzeń rzeczywiście pracuje już na poprawionej kompilacji, a ile nadal oczekuje na restart. Przy dużej liczbie stanowisk można wykorzystać narzędzia do zarządzania endpointami lub zasady administracyjne wymuszające aktualizację i ponowne uruchomienie.

Drugim krokiem jest analiza urządzeń o podwyższonym ryzyku. Jeżeli organizacja posiada system EDR, warto sprawdzić nietypowe zachowanie procesów przeglądarki, próby uruchamiania kolejnych programów, podejrzane połączenia sieciowe i alerty z ostatnich dni. Sam fakt posiadania nieaktualnego Chrome nie oznacza infekcji, ale przy podatności aktywnie wykorzystywanej w świecie rzeczywistym sensowne jest dokładniejsze sprawdzenie najbardziej wartościowych stanowisk. W firmach szybkość patchowania przeglądarki powinna być dziś traktowana podobnie jak aktualizowanie systemu operacyjnego.

Dlaczego przeglądarka stała się jednym z najważniejszych celów cyberataków?

Przeglądarka znajduje się dokładnie pomiędzy użytkownikiem a niemal całym internetem. Jest stale zalogowana do poczty, usług chmurowych, paneli administracyjnych, bankowości i narzędzi firmowych. Przechowuje cookies, tokeny sesji, historię i często zapisane hasła. Jednocześnie bez przerwy wykonuje kod pochodzący z zewnętrznych serwerów. Trudno znaleźć drugą aplikację, która łączyłaby tak dużą ekspozycję na niezaufane dane z dostępem do tak wielu ważnych usług.

Dlatego bezpieczeństwo przeglądarek opiera się na wielu warstwach jednocześnie. Nawet jeśli błąd występuje w rendererze, sandbox ma ograniczyć jego konsekwencje. Site Isolation oddziela różne witryny. Mechanizmy ochrony pamięci utrudniają wykorzystanie błędów, a automatyczne aktualizacje skracają czas ekspozycji. Atakujący próbują więc znaleźć kombinację słabości pozwalającą pokonać kilka zabezpieczeń jednocześnie. Szósty zero-day Chrome w 2026 roku przypomina, że współczesna przeglądarka jest właściwie małym systemem operacyjnym i powinna być chroniona z podobną uwagą.

Jak sprawdzić, czy Google Chrome jest już bezpieczny po najnowszej aktualizacji?

Na komputerze należy otworzyć menu z trzema kropkami, wybrać "Pomoc", a następnie "Google Chrome - informacje". Program pokaże pełny numer wersji i automatycznie wyszuka dostępne aktualizacje. Po ich zainstalowaniu konieczne jest ponowne uruchomienie przeglądarki. Dla stabilnej gałęzi Chrome poprawka CVE-2026-85046 została udostępniona w wersjach 152.0.7977.82/.83 dla Windows i macOS oraz 152.0.7977.82 dla Linux. Nowsza poprawiona wersja również jest oczywiście właściwym rozwiązaniem.

Na smartfonach warto wejść do Google Play lub App Store i sprawdzić dostępność aktualizacji ręcznie, szczególnie jeśli automatyczne instalowanie aplikacji jest wyłączone. Użytkownicy innych przeglądarek opartych na Chromium powinni wykonać analogiczną kontrolę w swoich aplikacjach. W praktyce cały proces zajmuje kilkadziesiąt sekund. Przy podatności, o której producent wprost mówi, że exploit istnieje już w realnym świecie, jest to jedna z tych sytuacji, w których odkładanie restartu przeglądarki "na później" nie ma większego sensu.

Czy szósta luka zero-day Chrome może nie być ostatnią w 2026 roku?

Nie da się przewidzieć, ile kolejnych aktywnie wykorzystywanych podatności zostanie ujawnionych przed końcem roku. Chrome zawiera ogromną ilość kodu, korzysta z wielu zewnętrznych komponentów i jest stale rozwijany. Jednocześnie przeglądarka jest analizowana przez tysiące badaczy bezpieczeństwa, zespoły Google oraz grupy ofensywne. W takim środowisku odkrywanie kolejnych błędów jest właściwie nieuniknione. Najważniejsze nie jest więc oczekiwanie świata bez podatności, ale skracanie czasu pomiędzy odkryciem problemu i instalacją poprawki na urządzeniach użytkowników.

CVE-2026-85046 dobrze pokazuje współczesny model walki o bezpieczeństwo przeglądarek. Badacz zgłasza lukę, producent przygotowuje poprawkę, równolegle pojawia się informacja o działającym exploicie, a szczegóły błędu pozostają ograniczone do czasu aktualizacji większości urządzeń. Wygrywa ten użytkownik i ta organizacja, które znajdują się na końcu tego łańcucha możliwie krótko. Dlatego po sześciu zero-dayach najważniejsza lekcja 2026 roku nie brzmi "przestań używać Chrome", lecz znacznie prościej - przeglądarka nie jest programem, którego aktualizacje można ignorować przez kilka tygodni.