Kolejny dzień zerowy Chrome'a trafia do Brukseli

Sześć dni zerowych w ciągu ośmiu miesięcy, nagroda tysiąca dolarów

Zespół Chrome w Google wydał wersje 152.0.7977.82 oraz .83 dla Windows i macOS, a także 152.0.7977.82 dla Linuksa, 3 i 4 września 2026 roku, łatając CVE-2026-85046 - błąd typu type confusion w silniku V8 obsługującym JavaScript i WebAssembly, który Google potwierdził jako już aktywnie wykorzystywany w praktyce. Błąd pozwala spreparowanej stronie internetowej oszukać kompilator V8 tak, by przyznał atakującemu dowolny dostęp do odczytu i zapisu na stercie przeglądarki, otwierając drogę do zdalnego wykonania kodu wewnątrz piaskownicy Chrome. Badacz Salvatore Gulizia zgłosił błąd 4 sierpnia 2026 roku i otrzymał nagrodę w wysokości 1000 dolarów. Google wstrzymał szczegóły techniczne, dopóki poprawka nie dotarła do większości użytkowników, co jest standardową praktyką przy aktywnie wykorzystywanej luce. To szósta aktywnie wykorzystywana luka dnia zerowego w Chrome załatana w 2026 roku, a każda z nich otrzymała ocenę CVSS 8.8 i wymagała awaryjnej łatki poza normalnym cyklem wydawniczym, zamiast czekać na zwykły harmonogram aktualizacji Chrome.

Osiem dni, zanim zegar zaczął tykać

Własna oś czasu Google pokazuje lukę, która ma znaczenie: firma ujawniła i załatała CVE-2026-85046 3 i 4 września, osiem dni przed datą wejścia w życie artykułu unijnego Cyber Resilience Act, który wymagałby formalnego zgłoszenia dokładnie takiego zdarzenia. Od 11 września 2026 roku artykuł 14 traktuje oprogramowanie takie jak Chrome jako produkt z elementami cyfrowymi, a gdy tylko dostawca dowie się, że luka jest aktywnie wykorzystywana, musi wysłać wczesne ostrzeżenie do krajowego punktu kontaktowego oraz do ENISA, unijnej agencji ds. cyberbezpieczeństwa, w ciągu 24 godzin, pełniejsze powiadomienie w ciągu 72 godzin oraz raport końcowy w ciągu 14 dni od udostępnienia poprawki. Gdyby Google odkrył i ujawnił ten sam błąd 12 września zamiast 3 września, identyczny ciąg zdarzeń - badacz zgłasza błąd w V8, Google potwierdza wykorzystywanie w praktyce, Google wydaje awaryjną łatkę - stałby się pierwszym prawdziwym testem Cyber Resilience Act, zamiast rutynowego ostrzeżenia. Sześć wykorzystanych luk dnia zerowego w Chrome w ciągu ośmiu miesięcy 2026 roku sprawia, że siódma, która pojawi się po tym, jak przepisy zaczną realnie obowiązywać, to kwestia czasu, a nie tego, czy w ogóle się pojawi.

Reguła decyzyjna dla osoby odpowiedzialnej za politykę łatek

Praktyczna lekcja dla każdej firmy w UE nie polega na czekaniu na urzędowe zgłoszenie, by dowiedzieć się o kolejnym dniu zerowym w Chrome, ponieważ własne notatki wydania Google mówiły, że załatane wersje będą trafiać do użytkowników przez kolejne dni i tygodnie nawet po tym, jak poprawka już istniała, co oznacza, że to szybkość automatycznej aktualizacji, a nie szybkość ujawnienia, decyduje o tym, jak długo flota laptopów pozostaje narażona. Osoba odpowiedzialna za politykę zabezpieczeń punktów końcowych powinna traktować szósty w tym roku dzień zerowy jako normę, a nie odstępstwo: skoro sześć incydentów pojawiło się mniej więcej co sześć do siedmiu tygodni w ciągu 2026 roku, właściwą postawą jest stały proces, który co tydzień sprawdza zainstalowane wersje Chrome względem najnowszej stabilnej wersji, zamiast ufać, że każda maszyna zaktualizuje się sama zgodnie z harmonogramem. Gdy zegar Cyber Resilience Act już działa, zespół IT z siedzibą w UE zyskuje także nowy sygnał wart obserwacji: historia zgłoszeń danego dostawcy do ENISA staje się przybliżonym wskaźnikiem tego, jak często jego produkty są aktywnie atakowane - bardziej konkretnym niż marketingowe zapewnienie o bezpieczeństwie klasy korporacyjnej i wartym sprawdzenia przed odnowieniem umowy, a nie po incydencie.

Czytaj dalej: SonicWall SMA1000: luki już aktywnie wykorzystywane  |  Zespoły Bezpieczeństwa UE Bez Głosu W Sprawie Astry