W kodzie Chrome przez ponad trzynaście lat leżała luka pozwalająca wyjść z sandboxa przeglądarki. Znalazł ją nie badacz bezpieczeństwa, tylko agentowa obudowa oparta na modelu Gemini, którą Google uruchomiło na początku 2026 roku. Wykorzystanie tej luki pozwoliłoby przejętemu procesowi renderowania wydostać się z izolacji i skłonić przeglądarkę do odczytania plików z dysku. To jeden z efektów pracy, którą zespół bezpieczeństwa Chrome opisał 30 lipca, a najmocniej brzmi w niej porównanie liczb.
Dwa wydania kontra dwadzieścia trzy
Chrome 149 i 150, wydane w czerwcu, przyniosły łącznie 1072 poprawki bezpieczeństwa. Poprzednie 23 wydania, czyli dorobek dwóch lat licząc od czerwca 2024 roku, dały ich 1036. Dwa wydania przebiły więc dwadzieścia trzy. Punktem odniesienia dla tego porównania jest Chrome 126 z czerwca 2024 roku.
Taką liczbę trzeba jednak czytać uważnie. Więcej poprawek nie znaczy, że przeglądarka nagle stała się dziurawa. Znaczy, że wykrywanie przyspieszyło, a znaczna część błędów została znaleziona wewnętrznie, zanim kod trafił do użytkowników. Google podaje przy tym, że w maju sam potok ciągłej integracji zatrzymał ponad 20 podatności, w tym jedną krytyczną. Żadna z nich nie dotarła do wersji, która trafia na komputery użytkowników.
Trzy systemy, nie jeden
W omówieniach tej historii łatwo o skrót myślowy, że “AI szuka błędów w Chrome”. W praktyce chodzi o trzy osobne narzędzia z trzech różnych lat.
Naptime powstał w 2024 roku wspólnie z Project Zero i polegał na wyposażeniu modelu w narzędzia do badania podatności. Rok później dołączył Big Sleep, agent zbudowany z DeepMind i Project Zero, który znalazł błędy w silniku JavaScriptu V8 oraz w warstwie graficznej. Na początku 2026 roku doszła obudowa agentowa oparta na Gemini, przeszukująca szerszą bazę kodu Chrome. To ona wypatrzyła wspomnianą trzynastoletnią ucieczkę z piaskownicy.
Warto zaznaczyć jedno. Luka została znaleziona, a nie zaobserwowana w atakach, i nic nie wskazuje, żeby ktokolwiek ją wcześniej wykorzystał.
Sam wiek tego błędu mówi jednak coś o skali zadania. Bezpieczeństwo Chrome dawno przestało polegać na łataniu oczywistych pomyłek w świeżym kodzie. Ten fragment leżał w bazie ponad trzynaście lat, w projekcie o otwartym kodzie i z jednym z najlepiej opłacanych programów nagród za luki na świecie. Google nie tłumaczy, dlaczego umknął wcześniejszym przeglądom, i sam nie stawia tu tezy o przewadze modeli nad ludźmi.
Najnudniejsza część okazała się najważniejsza
Najbardziej konkretnie oszacowana oszczędność dotyczy nie znajdowania błędów, tylko ich sortowania. Triage, czyli wstępna ocena napływających zgłoszeń, zajmowała wcześniej od pięciu do trzydziestu minut ludzkiej pracy na każde z nich.
Teraz robi to automat w czterech krokach. Odsiewa szum i duplikaty, próbuje odtworzyć błąd i zebrać zrzut stosu, dokłada metadane w rodzaju daty wprowadzenia błędu i poziomu ważności, a na koniec kieruje zgłoszenie do właściwego zespołu. Google szacuje oszczędność na setki godzin pracy programistów miesięcznie.
To jest moment, w którym ta historia przestaje dotyczyć wyłącznie Google. W naszym odczytaniu wąskim gardłem bywa nie brak pomysłu, gdzie szukać, tylko kolejka zgłoszeń, których nikt nie zdążył przejrzeć. Ten sam rytm widać było przy krytycznej luce w WordPressie, gdzie między publikacją poprawki a jej wdrożeniem mijały tygodnie.
Czego Google sam nie obiecuje
Najbardziej wiarygodna część wpisu to lista rzeczy, które nie działają, i akurat tej części brakuje w większości omówień.
Po pierwsze, modele generują błędne raporty. Google zachęca twórców projektów do dodawania plików SECURITY.md, żeby modele lepiej rozumiały, gdzie w danym projekcie przebiegają granice zaufania. Po drugie, klasyczny fuzzing, czyli zasypywanie programu losowymi danymi, nadal wypada lepiej przy błędach wynikających z odległych zależności między różnymi częściami kodu. Po trzecie, same modele pracują pod ścisłym reżimem: analizują kod wyłącznie w spoczynku, na odizolowanych maszynach i nigdy w trybie nieograniczonym.
Osobno warto odnotować skutek uboczny, który dotyczy całej branży. Do Google napłynęło w tym roku więcej zgłoszeń błędów niż przez cały 2025 rok. Firma przebudowała z tego powodu program nagród za luki tak, żeby kierować badaczy na zgłoszenia uzupełniające to, co znajduje sama. Mniejsze zespoły prowadzące własne programy zderzą się z tym samym zjawiskiem szybciej, bo nie mają jak filtrować takiej fali.
Modele to tylko jedna z warstw
Warto zauważyć, że we wpisie Google model językowy nie występuje jako jedyne narzędzie. Równolegle idzie znacznie mniej efektowna praca nad samym kodem. Firma podaje, że 97 procent własnego kodu Chrome kompiluje się bez ostrzeżeń przy włączonych rygorystycznych kontrolach niebezpiecznych operacji na buforach.
To liczba z zupełnie innego porządku niż agent przeszukujący repozytorium. Chodzi o zamykanie całych klas błędów regułami kompilatora, a nie o wyszukiwanie pojedynczych pomyłek po fakcie. Jedno i drugie działa w innym momencie pracy i żadne nie zastępuje drugiego.
Osobno idzie potok ciągłej integracji. Zatrzymanie ponad dwudziestu podatności w maju, w tym jednej krytycznej, oznacza, że nie trafiły one do produkcyjnych wydań Chrome. Tu jednak bez uproszczeń: Google wiąże ten wynik z narzędziami opartymi na AI wpiętymi w potok, a nie ze zwykłym skanerem. Przenośny dla mniejszego zespołu jest sam układ, czyli przesunięcie kontroli przed wydanie, a nie konkretne narzędzia Google.
Co z tym zrobić
Dla użytkownika wniosek jest banalny, ale rzadko realizowany. Skoro dwa wydania przyniosły tyle poprawek co poprzednie dwa lata, odkładanie restartu przeglądarki przestało być neutralne. Bezpieczeństwo Chrome opiera się na tym, że aktualizacja faktycznie się instaluje, a nie czeka tygodniami na zamknięcie kart. Sprawdzenie wersji zajmuje kilkanaście sekund w menu pomocy przeglądarki i warto to zrobić od razu po przeczytaniu tego akapitu.
Dla zespołu budującego oprogramowanie ciekawszy jest inny wniosek. Doug Turner, dyrektor inżynierii Chrome, ujął to tak: “By applying models like Gemini, we are preemptively fixing vulnerabilities, outpacing our adversaries and making Chrome safer with every update”. W tłumaczeniu: dzięki modelom takim jak Gemini naprawiamy podatności zawczasu, wyprzedzamy przeciwników i z każdą aktualizacją czynimy Chrome bezpieczniejszym. Zwrot “zawczasu” jest tu istotniejszy niż nazwa modelu. Cała przewaga polega na przesunięciu pracy przed wydanie, a nie po zgłoszeniu.
Jest też w tym wpisie jedna rada, którą można wdrożyć od razu i za darmo. Google zachęca twórców projektów do dodawania pliku SECURITY.md, żeby modele analizujące kod lepiej rozumiały, gdzie przebiegają granice zaufania w danym projekcie. Brzmi to jak formalność, ale przekłada się wprost na liczbę bezsensownych zgłoszeń, które ktoś potem musi przeczytać. Jeśli utrzymujesz publiczne repozytorium, to najtańsza rzecz z całej tej historii, jaką da się u siebie powtórzyć. Ten sam wzorzec widać było przy fałszywych serwerach MCP, gdzie decyzja podjęta wcześniej kosztowała nieporównanie mniej niż reakcja po fakcie.
Pierwsza Misja AI · Kodożercy
Rozumiesz zagrożenia AI, gdy rozumiesz jak naprawdę działa.
Kurs Pierwsza Misja AI ma dedykowaną lekcję o ciemnej stronie AI: halucynacje, deepfakes, manipulacja. Zanim zaczniesz się bać, zacznij rozumieć.
Poznaj pełny program →
FAQ
Czy 1072 poprawki oznaczają, że Chrome był dziurawy?
Nie w takim sensie, w jakim brzmi ta liczba. Znaczna część błędów została wykryta wewnętrznie, zanim kod trafił do wydania, a Google podaje przykład maja, kiedy sam potok ciągłej integracji zatrzymał ponad 20 podatności. Wyższa liczba poprawek jest więc przede wszystkim miarą sprawniejszego wykrywania. Nie da się z niej wyczytać, ile z tych błędów byłoby realnie wykorzystanych.
Czy AI zastąpiła w Google badaczy bezpieczeństwa?
Nie, choć zmieniła podział pracy. Google przebudowało program nagród za luki, żeby kierować zewnętrznych badaczy na zgłoszenia uzupełniające to, co firma znajduje sama, a nie żeby z nich zrezygnować. Sam wpis wymienia też metody, w których klasyczne narzędzia wciąż wypadają lepiej od modeli, na czele z fuzzingiem przy błędach wynikających z odległych zależności w kodzie.
Podsumowanie
Chrome 149 i 150 przyniosły w czerwcu 1072 poprawki bezpieczeństwa, czyli więcej niż 23 poprzednie wydania z dwóch lat razem wzięte. Za częścią z nich stoją trzy osobne systemy budowane od 2024 roku: Naptime, Big Sleep i obudowa agentowa oparta na Gemini. Ta ostatnia wypatrzyła ucieczkę z piaskownicy obecną w kodzie ponad trzynaście lat. Największa oszczędność wzięła się jednak z najmniej efektownego etapu, czyli automatycznego sortowania zgłoszeń, które wcześniej zajmowało od pięciu do trzydziestu minut na sztukę. Sam Google wskazuje przy tym granice metody: modele generują błędne raporty, fuzzing nadal bywa skuteczniejszy, a fala zgłoszeń wygenerowanych z pomocą AI wymusiła przebudowę programu nagród za luki.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
