Chrome 151 załatał ponad 400 luk. Ten przypadek pokazuje, dlaczego ludzie wciąż wygrywają z AI

Sama liczba poprawek robi wrażenie, ale nie wyczerpuje tematu. Chrome 151 jest interesującym studium przypadku także dlatego, że pokazuje, jak odkrywa się dziś błędy. Około 90 proc. podatności wykryły wewnętrzne zespoły Google, korzystające z fuzzingu, sanitizerów i narzędzi wspieranych przez uczenie maszynowe. Pozostałą część znaleźli zewnętrzni badacze uczestniczący w programie bug bounty — i to oni wykryli błędy, które automatyzacja nadal często przeocza .

Chrome 151: dwie fale porządkowania powierzchni ataku

Aktualizacja z 29 lipca: 370 luk i 7 krytycznych podatności

Pierwsza z omawianych aktualizacji trafiła do stabilnego kanału jako Chrome 151.0.7922.71/.72 dla Windowsa, macOS i Linuksa. Wersja 151.0.7922.71/.72 była również dystrybuowana na Androida .

Siedem krytycznych podatności, oznaczonych numerami CVE-2026-17650–CVE-2026-17656, obejmowało:

• błędy typu use-after-free, czyli użycie zwolnionego obszaru pamięci, w komponentach Compositing, Views, Skia i Ozone ;
• problemy z niewystarczającą walidacją danych wejściowych w Dawn i warstwie graficznej ANGLE ;
• warunek wyścigu w komponencie aktualizatora Chrome .

Szczególnie istotna była podatność CVE-2026-11645 w V8, czyli silniku JavaScriptu Chrome. Ten błąd odczytu i zapisu poza granicami pamięci otrzymał ocenę CVSS 8,8 i znajdował się już w katalogu CISA Known Exploited Vulnerabilities — amerykańskiej liście podatności potwierdzonych jako wykorzystywane w atakach — zanim Google opublikowało poprawkę .

Aktualizacja z 7 sierpnia: 41 kolejnych luk

Drugi pakiet udostępniono jako wersje 151.0.7922.108/.109 dla Windowsa i macOS oraz 151.0.7922.108 dla Linuksa . Zawierał on 41 poprawek: 6 dla luk krytycznych i 35 dla podatności o wysokim poziomie zagrożenia .

Krytyczne błędy obejmowały:

• pięć podatności use-after-free w WebGL, Aura, Skia i Views ;
• zapis poza granicami pamięci w silniku graficznym ANGLE .

Spośród 35 luk o wysokim poziomie zagrożenia 24 dotyczyły bezpieczeństwa pamięci. Takie błędy mogą prowadzić między innymi do awarii, uszkodzenia danych lub wykonania kodu przez napastnika .

Dlaczego w źródłach pojawia się także liczba 382?

Bilans Chrome 151 nie jest całkowicie jednoznaczny. Część publikacji z początku czerwca mówi o kompilacji, w której załatano 382 luki, w tym 15 krytycznych. Nie ma jednak pełnej zgodności co do tego, czy chodziło o poprawki przed wydaniem stabilnym, czy o częściowo nakładające się zestawy zmian .

W tym tekście przyjmujemy liczby 370 i 41, ponieważ dotyczą dwóch stabilnych wydań opisanych w wielu źródłach bezpieczeństwa. Ich suma daje 411 poprawek.

Kto znalazł luki: automaty kontra badacze

Co znalazły automaty?

Zespoły Google korzystają z rozbudowanego zestawu narzędzi do fuzzingu i wykrywania problemów z pamięcią, w tym AddressSanitizer, MemorySanitizer i Control Flow Integrity . Część tych procesów wykorzystuje także uczenie maszynowe, aby kierować testy w stronę złożonych i potencjalnie ryzykownych fragmentów kodu .

Automatyzacja dobrze radzi sobie z tym, co można nazwać „znanymi nieznanymi”: wzorcami takimi jak use-after-free, przepełnienia bufora czy użycie niezainicjalizowanej pamięci. Fuzzery uruchamiają ogromną liczbę wariantów danych wejściowych i sprawdzają, które ścieżki wykonania prowadzą do niebezpiecznych zachowań.

W pierwszej aktualizacji Google przypisało swoim zespołom 349 z 370 błędów — zdecydowaną większość całego pakietu . To właśnie skala jest największą przewagą automatyzacji: narzędzia mogą testować miliony kombinacji szybciej, niż byłby w stanie zrobić to człowiek.

Co nadal wymaga człowieka?

Zewnętrzni badacze dostarczyli mniej zgłoszeń, ale część z nich miała strategiczne znaczenie.

W przypadku wydania z 29 lipca badacze znaleźli około 24 luki i otrzymali nagrody od 2 000 do 36 000 dolarów. Najwyższa pojedyncza wypłata — 36 000 dolarów — dotyczyła błędu use-after-free w komponencie GPU, oznaczonego jako CVE-2026-13789 .

W aktualizacji z 7 sierpnia zewnętrzni badacze odpowiadali za 12 z 41 zgłoszeń, czyli niemal jedną trzecią całego pakietu . Wśród wymienionych osób znaleźli się Muhammad Alifa Ramdhan, Pan ZhenPeng i Billy Jheng Bing Jhong z STAR Labs SG Pte. Ltd. Zgłosili oni podatność use-after-free w WebGL, oznaczoną jako CVE-2026-19170 . Inną krytyczną lukę w WebGL — CVE-2026-19137 — zgłoszono anonimowo .

Google przyznało również nagrodę w wysokości 5 000 dolarów SungHyunowi Kimowi za CVE-2026-19169, czyli błąd niewystarczającej walidacji w komponencie Contextual Tasks . W komunikatach dotyczących tego wydania odnotowano także dwie wypłaty po 500 dolarów .

Wspólnym elementem takich odkryć jest kreatywne myślenie w roli napastnika. Badacz musi czasem połączyć zachowanie kilku komponentów, znaleźć nietypową kolejność zdarzeń albo przewidzieć rzadki przebieg programu, którego standardowy fuzzer nie potrafił wywołać .

Rust jako sposób na zapobieganie części błędów

Chrome 151 przyniósł również zmianę, która nie była reakcją na pojedynczą lukę, lecz próbą ograniczenia całej klasy problemów. Google zaktualizowało silnik parsowania XML, zastępując go implementacją w bezpiecznym pamięciowo języku Rust w typowych scenariuszach, w których nie jest potrzebne XSLT .

To element szerszego trendu w branży. Microsoft i inni dostawcy coraz częściej wykorzystują Rusta, aby eliminować błędy związane z bezpieczeństwem pamięci już na etapie projektowania i kompilacji .

Nie oznacza to, że Rust rozwiąże wszystkie problemy. Nie usuwa błędów logicznych ani wad projektowych. Może jednak bezpośrednio ograniczyć ryzyko takich podatności jak use-after-free i przepełnienia bufora — czyli kategorii, która stanowiła znaczną część krytycznych problemów naprawianych w Chrome 151.

Wniosek: AI nie zastępuje badaczy, tylko zwiększa ich zasięg

Chrome 151 dobrze pokazuje, dlaczego w cyberbezpieczeństwie mówi się o AI jako o mnożniku możliwości, a nie cudownym rozwiązaniu:

• AI i automatyzacja zapewniają skalę. Fuzzing i sanitizery wykrywają ogromną liczbę typowych błędów bezpieczeństwa pamięci, szczególnie tych, które da się opisać powtarzalnym wzorcem .
• Ludzie zapewniają głębię i oryginalność. Badacze potrafią analizować interakcje między komponentami, nietypowe warunki wyścigu i scenariusze, których nie da się łatwo zdefiniować w regułach testu .
• Najlepiej działa model hybrydowy. Automaty wychwytują „znane nieznane” na masową skalę, a ludzie skupiają się na błędach logicznych, łańcuchach exploitów i sytuacjach granicznych — czyli na tym, czego narzędzie nie umie wcześniej przewidzieć.

Łącznie 411 poprawek Chrome 151 nie byłoby możliwe dzięki jednej metodzie. Dane z aktualizacji z 7 sierpnia, w której badacze bug bounty znaleźli 12 z 41 luk, są mocnym argumentem przeciwko tezie, że automatyzacja wypiera człowieka .

Co powinni zrobić użytkownicy?

Chrome na komputerach powinien zaktualizować się automatycznie. Warto jednak sprawdzić to ręcznie, wybierając Ustawienia > Informacje o Chrome i upewniając się, że przeglądarka ma wersję 151.0.7922.108/.109 lub nowszą .

Użytkownicy Androida powinni sprawdzić dostępność najnowszej aktualizacji Chrome w ustawieniach systemu lub w sklepie z aplikacjami. Dla pierwszej fali poprawek wskazywano wersję 151.0.7922.71/.72 .

Ponieważ jedna z naprawionych luk — CVE-2026-11645 — była już aktywnie wykorzystywana, odkładanie aktualizacji nie jest dobrym pomysłem .