Dwa zero-day Chrome w marcu 2026: CVE-2026-3909 i CVE-2026-5281

Marzec 2026 przyniósł dwa osobne alarmy zero-day dla Chrome. 13 marca Google opublikowało poprawkę dla CVE-2026-3909, błędu zapisu poza buforem w bibliotece graficznej Skia, zgłoszonego przez Google Threat Analysis Group. 31 marca pojawiła się poprawka dla CVE-2026-5281, błędu use-after-free w Dawn — implementacji WebGPU. W obu komunikatach Google potwierdziło, że exploit istniał i był używany w środowisku rzeczywistym.

CVE-2026-3909 naprawiono w Chrome 146.0.7680.80 na desktopie. Dla drugiego zdarzenia stabilna gałąź otrzymała 146.0.7680.177/178 na Windows i macOS oraz 146.0.7680.177 na Linux; odpowiadająca aktualizacja trafiła również do Androida. Google ograniczyło dostęp do szczegółów błędów do czasu aktualizacji większości użytkowników, więc nie ma podstaw do dopowiadania konkretnego łańcucha lub grupy atakującej.

Co oznaczają obie klasy błędów

Out-of-bounds write pozwala zapisać dane poza przeznaczonym buforem. Use-after-free oznacza użycie obiektu po zwolnieniu jego pamięci. Obie klasy mogą prowadzić do awarii albo kontrolowanej korupcji pamięci. W przeglądarce skuteczne przejęcie systemu często wymaga jeszcze wyjścia z sandboxa; potwierdzenie exploita nie oznacza automatycznie, że każdy przypadek dawał pełne uprawnienia systemowe.

Skia przetwarza grafikę i formaty renderowane przez strony. Dawn obsługuje WebGPU i kontaktuje się z warstwą GPU. To powierzchnie osiągalne przez treść internetową, dlatego nie można czekać na klasyczny miesięczny cykl patchowania.

Runbook aktualizacji przeglądarek

Najpierw sprawdź faktyczną wersję procesu na urządzeniu, a nie tylko status polityki MDM. Wymuś restart przeglądarki — pobrana aktualizacja nie chroni działającego starego procesu. Zmierz udział urządzeń poniżej wersji docelowej po 24 i 48 godzinach, uwzględniając laptopy poza VPN.

Dla niewspieranych systemów operacyjnych trzeba zaplanować migrację; „najnowsza dostępna” wersja może nadal być podatna. Przeglądarki oparte na Chromium mają własny harmonogram, więc numer Chrome nie dowodzi, że Edge, Brave lub aplikacja Electron otrzymały ten sam patch. Inwentaryzuj silnik w aplikacjach desktopowych.

W EDR szukaj korelacji: proces renderera, awaria lub anomalia GPU, a następnie nietypowy proces potomny, zapis pliku wykonywalnego albo połączenie sieciowe. Izolacja przeglądarki, blokada niepotrzebnego WebGPU i least privilege ograniczają skutki, ale nie zastępują aktualizacji.

Te dwa zero-day pokazują, dlaczego zarządzanie podatnościami musi obsługiwać poprawki poza harmonogramem. Dla aktywnie wykorzystywanej przeglądarki KPI powinno być liczone w godzinach. Możemy sprawdzić realny poziom patchowania i obejścia na endpointach.

Priorytety dla różnych grup urządzeń

Najpierw aktualizuj stacje administratorów, osoby z dostępem do finansów, dziennikarzy, zarząd i użytkowników obsługujących skrzynki wspólne. Są bardziej atrakcyjnym celem dla exploitów kierowanych. Następnie obejmij całą flotę, bo strona watering-hole lub złośliwa reklama nie musi znać roli użytkownika.

VDI i kioski wymagają osobnego procesu. Złoty obraz może być poprawiony, ale działająca sesja nadal używa starej wersji. W środowisku non-persistent upewnij się, że następne uruchomienie pobiera nowy obraz i że pool nie przywróci starego snapshotu.

Co zrobić, gdy urządzenie było narażone

Samo wejście na stronę nie dowodzi wykorzystania. Jeżeli jednak urządzenie wysokiego ryzyka używało podatnej wersji w czasie aktywnej kampanii i EDR pokazuje anomalię renderera, odizoluj je oraz zachowaj pamięć i telemetrię. Przejrzyj procesy potomne, pobrania, mechanizmy persistence, tokeny przeglądarki i logowania z nowego urządzenia.

Zmiana haseł na potencjalnie przejętej stacji może przekazać nowe hasło napastnikowi. Najpierw użyj czystego urządzenia, unieważnij sesje, a dopiero potem zmień poświadczenia. Dla kont uprzywilejowanych sprawdź rejestracje MFA i aplikacje OAuth.

Utrzymanie przeglądarek jako programu bezpieczeństwa

Zdefiniuj ownera dla Chrome, Edge, Firefox i aplikacji Electron. Zbieraj wersję codziennie, wymuszaj restart po okresie karencji i blokuj logowanie do krytycznych SaaS z urządzeń poniżej minimum. Raport powinien pokazywać medianę i p95 czasu aktualizacji, nie jedynie „zgodność 95%”.

Czy wyłączenie JavaScript chroni? Może zablokować część łańcuchów, ale Skia i inne parsery pracują również na mediach. To mitygacja awaryjna o dużym koszcie użytkowym, nie zamiennik patcha.

Komunikacja bez wywoływania paniki

Użytkownik potrzebuje prostego polecenia: zapisz pracę, otwórz „Chrome — informacje”, poczekaj na aktualizację i uruchom ponownie przeglądarkę. Nie wysyłaj technicznego CVE bez działania. Administrator powinien równolegle wymusić update polityką i sprawdzać wersję telemetrycznie, ponieważ deklaracja użytkownika nie jest dowodem.

Jeśli część urządzeń nie może zostać poprawiona, odetnij je od poczty, paneli administracyjnych i aplikacji finansowych do czasu migracji. Wyjątek powinien mieć właściciela i datę wygaśnięcia. Aktywna eksploatacja zmienia ryzyko z hipotetycznego na operacyjne, nawet gdy Google nie ujawnia celu kampanii.

---

Źródła pierwotne: Chrome Releases — CVE-2026-3909, 13 marca, Chrome Releases — CVE-2026-5281, 31 marca.