Google opublikował 5 maja 2026 r. nową stabilną wersję przeglądarki Chrome 148, która załatała aż 127 podatności bezpieczeństwa na Windows, macOS i Linuksie. To nie była kosmetyczna aktualizacja „dla świętego spokoju”, tylko naprawdę duży pakiet poprawek obejmujący 3 luki krytyczne, ponad 30 luk wysokiej wagi i dziesiątki błędów średniego oraz niskiego ryzyka. Oficjalny komunikat Chrome Releases potwierdza zarówno numer wersji, jak i liczbę naprawionych problemów.
Najkrócej mówiąc: nie chodzi o jedną spektakularną zero-day, tylko o zbiorcze, duże czyszczenie bezpieczeństwa w ramach nowego wydania przeglądarki. I właśnie dlatego temat jest ciekawy — bo wielu użytkowników widzi tylko „zaktualizuj Chrome”, a nie rozumie, że za jednym restartem przeglądarki stoi często cała góra napraw w silniku renderującym, JavaScripcie, GPU, multimediach i innych podsystemach.
Co dokładnie się stało
Google wypchnął do kanału Stable wersję:
- 148.0.7778.96 dla Linuksa,
- 148.0.7778.96/97 dla Windows i macOS.
W oficjalnym wpisie Google podał wprost, że ta wersja zawiera 127 security fixes. Dla porównania, poprzednia desktopowa aktualizacja Stable z 22 kwietnia 2026 r. zawierała 19 poprawek bezpieczeństwa. To pokazuje skalę różnicy: najnowszy pakiet był ponad sześciokrotnie większy od poprzedniego stabilnego wydania.
To nie oznacza automatycznie, że „nagle Chrome zrobił się dużo bardziej dziurawy” w ciągu kilku dni. Bardziej prawdopodobny i zgodny z komunikatem Google wniosek jest taki, że Chrome 148 zebrał pełen dorobek danego cyklu wydawniczego: błędy zgłoszone przez badaczy zewnętrznych, własne audyty Google, fuzzing i inne inicjatywy wewnętrzne. Google pisze o tym wprost, dziękując badaczom i zaznaczając, że szeroka grupa napraw pochodzi z internal audits, fuzzing and other initiatives.
Czego dotyczyły podatności
Najpoważniejsze błędy dotknęły bardzo wrażliwych komponentów przeglądarki, czyli tych, które przetwarzają nieufne dane z internetu: HTML, JavaScript, multimedia, grafika i komunikacja.
Luki krytyczne
Google wskazał trzy błędy o wadze Critical:
- CVE-2026-7896 – integer overflow w Blink, czyli silniku renderującym strony,
- CVE-2026-7897 – use-after-free w komponencie Mobile,
- CVE-2026-7898 – use-after-free w Chromoting.
Blink jest szczególnie istotny, bo to serce przetwarzania treści webowych. Jeśli tam pojawia się błąd typu integer overflow albo memory corruption, ryzyko zdalnego wykorzystania rośnie bardzo wyraźnie. SecurityWeek zaznacza, że CVE-2026-7896 mogła prowadzić do heap memory corruption przez odpowiednio spreparowaną stronę HTML.
Luki wysokiej wagi
Pakiet obejmował też ponad 30 usterek high severity, między innymi w:
- V8,
- ANGLE,
- Fonts,
- Media,
- SVG,
- DOM,
- Fullscreen,
- ServiceWorker,
- GPU,
- Skia,
- Passwords,
- WebRTC,
- Presentation API,
- Chromoting.
To ważne, bo ten rozrzut pokazuje, że nie była to jedna pojedyncza wada architektoniczna, tylko szerokie porządkowanie wielu obszarów. Gdy lista obejmuje renderowanie, JS engine, GPU, multimedia i komunikację, mówimy o szerokiej powierzchni ataku przeglądarki — dokładnie tam, gdzie atakujący najchętniej szukają błędów.
Czy to była duża paczka
Tak. Bardzo duża.
Oficjalnie Google potwierdził 127 poprawek bezpieczeństwa. Już samo to robi wrażenie, ale dopiero porównanie z poprzednim stabilnym wydaniem pokazuje skalę: 19 poprawek w Chrome 147 kontra 127 poprawek w Chrome 148.
Zewnętrzne media bezpieczeństwa też traktują ten release jako coś ponadprzeciętnego. SecurityWeek opisał go jako wydanie z 127 security fixes, w tym trzema krytycznymi i dziesiątkami wysokiego ryzyka, a PCWorld zauważył, że było to ponad dwa razy więcej niż w poprzedniej wersji.
Czy to rekord wszech czasów? Tego bez pełnego historycznego przeglądu wszystkich wydań Chrome nie da się uczciwie stwierdzić. Ale można bezpiecznie powiedzieć, że to był wyjątkowo duży i nietypowo ciężki pakiet.
Dlaczego ta paczka była tak duża
Tu warto odciąć sensację od faktów.
Nie ma oficjalnego komunikatu Google w stylu: „to było opóźnione, bo wydarzyło się X”. To znaczy, że nie należy zmyślać teorii o spisku, opóźnieniu albo ukrywaniu problemu. Z dostępnych źródeł wynika raczej coś bardziej przyziemnego: Chrome 148 był normalnym wydaniem Stable nowego milestone’u, a duża liczba napraw to efekt zsumowania:
- zgłoszeń badaczy zewnętrznych,
- pracy własnych zespołów Google,
- fuzzingu,
- auditów bezpieczeństwa,
- poprawek, które dojrzewały przez cały cykl rozwojowy.
Daty zgłoszeń pokazane przy poszczególnych lukach też to wspierają. Wiele z nich raportowano w marcu i kwietniu 2026 r., a stabilne wydanie pojawiło się 5 maja 2026 r.. To wygląda bardziej na standardowy cykl napraw i wdrożenia do kolejnego milestone’u niż na „strasznie późną reakcję”.
Dlaczego szczegóły są ujawniane dopiero częściowo
Google bardzo wyraźnie zaznacza, że szczegóły części błędów i linki do ticketów mogą pozostać ograniczone, dopóki większość użytkowników nie otrzyma aktualizacji. Firma podaje też drugi powód: podobne ograniczenia są utrzymywane, jeśli wada dotyczy biblioteki zewnętrznej, z której korzystają też inne projekty i które nie zdążyły jeszcze wypuścić własnych poprawek.
To nie jest „dziwna tajemnica”, tylko standardowa praktyka bezpieczeństwa. Gdyby pełne, techniczne szczegóły były publikowane natychmiast, a połowa świata nadal miałaby stary Chrome, to atakujący dostaliby gotową instrukcję obsługi. Innymi słowy: cisza techniczna przez chwilę chroni spóźnialskich.
Czy były aktywnie wykorzystywane zero-daye
W komunikacie dla Chrome 148 Google nie napisał, że te 127 luk obejmuje aktywnie wykorzystywaną zero-day. To ważne rozróżnienie. Wcześniejsze kwietniowe wydania Chrome faktycznie zawierały osobne alerty dotyczące błędów wykorzystywanych w praktyce, ale przy tej zbiorczej majowej paczce źródła, które sprawdziliśmy, mówią o dużym pakiecie napraw, nie o jednej centralnej zero-day wykorzystywanej „tu i teraz”.
To dobra wiadomość, ale tylko połowicznie. Brak oficjalnego „exploited in the wild” nie oznacza, że można temat zignorować. Przy takiej liczbie błędów pamięciowych w Blink, V8, ANGLE czy GPU ryzyko pojawienia się exploitów po publikacji update’u jest realne.
Co to oznacza dla użytkownika i firmy
Dla zwykłego użytkownika sprawa jest prosta: zaktualizować Chrome i zrestartować przeglądarkę. Koniec filozofii.
Dla firm to jest trochę większa sprawa, bo aktualizacja Chrome nie dotyczy tylko „czy YouTube będzie działał”, ale realnie powierzchni ataku na stacjach roboczych. Przeglądarka jest dziś jednym z głównych wektorów ryzyka: otwierasz strony, logujesz się do paneli, pracujesz na SaaS-ach, uruchamiasz aplikacje webowe i przetwarzasz nieufny content praktycznie bez przerwy. Gdy w jednym wydaniu wpada 127 security fixes, to jest to mocny sygnał, że przeglądarka powinna być traktowana jak krytyczny komponent bezpieczeństwa, a nie „program do internetu”.
Jak sprawdzić wersję i zaktualizować Chrome
Najprościej:
- Otwórz Chrome.
- Wejdź w Pomoc → Google Chrome albo wpisz w pasku adresu
chrome://settings/help. - Chrome sam sprawdzi aktualizacje i pobierze nową wersję.
- Zrestartuj przeglądarkę, bo bez tego poprawki mogą nie wejść w życie do końca.
Docelowo szukasz co najmniej:
- 148.0.7778.96 na Linuksie,
- 148.0.7778.96/97 na Windows i macOS.
W środowisku firmowym warto dodatkowo sprawdzić polityki aktualizacji przeglądarki, bo czasem problemem nie jest brak paczki, tylko opóźnione wdrożenie przez zarządzanie centralne.
Jak ograniczyć podobne ryzyko w przyszłości
Nie unikniesz wszystkich błędów w przeglądarce, bo to potężny i bardzo złożony kawałek oprogramowania. Ale możesz zmniejszyć ryzyko:
- nie odkładaj aktualizacji przeglądarki,
- aktualizuj też przeglądarki oparte na Chromium jak Edge, Brave czy Opera, bo one również dziedziczą część ryzyk z upstreamu,
- oddzielaj pracę uprzywilejowaną od zwykłego surfowania,
- uważaj na nieznane pliki i strony,
- utrzymuj aktualny system i EDR/AV,
- w firmie trzymaj sensowną politykę szybkiego patchowania przeglądarek.
To nie są rady rewolucyjne, ale właśnie takie rzeczy robią różnicę między „incydentem z internetu” a zwykłym restartem przeglądarki po update.
Sekcja praktyczna
Szybka checklista
- Sprawdź wersję Chrome w
chrome://settings/help. - Jeśli masz starszą niż 148.0.7778.96/97, zaktualizuj od razu.
- Uruchom Chrome ponownie, bo samo pobranie update’u nie wystarczy.
- W firmie sprawdź inne przeglądarki oparte na Chromium, bo mogą potrzebować własnego rolloutu po upstreamowej poprawce.
- Nie traktuj tej paczki jako jednej ciekawostki medialnej — 127 poprawek oznacza, że było co czyścić.
Garść ciekawostek
- Google wypłacił co najmniej 43 000 USD za krytyczną lukę CVE-2026-7896 w Blink.
- Najwyższa publicznie wskazana nagroda w tym wydaniu to 55 000 USD za błąd out-of-bounds read/write w V8.
- Google podał, że wiele błędów wykryto dzięki narzędziom takim jak AddressSanitizer, MemorySanitizer, libFuzzer czy AFL.
- Chrome 147 z 22 kwietnia 2026 r. zawierał tylko 19 poprawek bezpieczeństwa, więc skok do 127 w Chrome 148 był naprawdę wyraźny.
- Google zastrzegł, że część ticketów i szczegółów technicznych pozostanie ograniczona, dopóki większość użytkowników nie zainstaluje aktualizacji.
Podsumowanie
Ostatnia duża paczka poprawek Chrome to nie był drobiazg. Chrome 148 przyniósł 127 napraw bezpieczeństwa, w tym 3 krytyczne i dziesiątki wysokiego ryzyka. Najmocniej ucierpiały kluczowe komponenty przeglądarki: Blink, V8, ANGLE, GPU, multimedia i inne elementy odpowiedzialne za przetwarzanie nieufnych danych z internetu.
Czy Google „zareagował późno”? Z dostępnych źródeł nie wynika, by chodziło o jakieś nadzwyczajne opóźnienie. Bardziej wygląda to na duże wydanie zbiorcze nowego milestone’u, które zebrało efekty całego cyklu rozwojowego i pracy badaczy oraz zespołów wewnętrznych. Za to jeden wniosek jest bardzo prosty: jeśli nie masz jeszcze najnowszej wersji Chrome, pora to naprawić.
Źródła
- Google Chrome Releases, Stable Channel Update for Desktop, 5 maja 2026 r.
- Google Chrome Releases, Stable Channel Update for Desktop, 22 kwietnia 2026 r.
- SecurityWeek, Chrome 148 Rolls Out With 127 Security Fixes, 7 maja 2026 r.
- Forbes, Critical New Google Update — 127 Chrome Security Vulnerabilities Confirmed, wynik wyszukiwania potwierdzający skalę i recencję publikacji.
Autor: Redakcja youITcare · AI-Assisted
Artykuł opracowany przy wsparciu narzędzi sztucznej inteligencji, pod redakcyjnym nadzorem zespołu youITcare.