2 czerwca Google wydał Chrome 149 — i załatał 429 podatności naraz. To największa liczba luk usuniętych w pojedynczej aktualizacji Chrome w historii. Dla porównania, które robi wrażenie: Chrome 149 przewyższa liczbą poprawek bezpieczeństwa sumę wszystkich łatek Chrome wydanych w całym 2025 roku — w jednym skoku wersji.
Wśród nich 22 krytyczne, od CVE-2026-10881 do CVE-2026-10902, w większości use-after-free. Najpoważniejsza, CVE-2026-10881, ma 9.6 w skali CVSS — błąd odczytu i zapisu poza zakresem w silniku graficznym ANGLE, pozwalający spreparowanej stronie uciec z piaskownicy Chrome i wykonać kod na systemie hosta. Google zapłacił za jej zgłoszenie 97 000 dolarów.
Ale liczba 429 nie jest tu najważniejsza. Najważniejsze jest, dlaczego nagle jest tak wysoka — i co to mówi o tym, gdzie przesuwa się trudny problem w bezpieczeństwie.
To nie był jeden incydent. To jest zmiana tempa.
Łatwo przeczytać „429 łatek" jako reakcję na jakieś jedno wielkie odkrycie. Tak nie było. Liczba 429 nie jest wynikiem pojedynczego incydentu bezpieczeństwa, lecz odzwierciedla trwałe przyspieszenie wewnętrznego programu wykrywania błędów Chrome.
Źródłem tego przyspieszenia jest AI. Analitycy przypisują ten skok częściowo rosnącemu użyciu narzędzi fuzzingu wspomaganego AI, które stały się znacząco skuteczniejsze w wykrywaniu problemów bezpieczeństwa pamięci głęboko w podsystemach grafiki, JavaScriptu i sieci przeglądarki. Google stosuje AI-fuzzing do swojej bazy kodu na szeroką skalę — i wyniki pojawiają się w notatkach wydania w bezprecedensowej ilości.
Profil odkryć to potwierdza. Spośród 22 krytycznych luk 19 znalazł wewnętrznie sam zespół Google'a, nie zewnętrzni badacze. To nie jest obraz fali zgłoszeń z zewnątrz — to obraz wewnętrznej maszyny, która zaczęła znajdować błędy szybciej, niż kiedykolwiek wcześniej. Google nie powiązał oficjalnie rekordu 429 wprost z AI, ale jest sygnał na papierze: przebudowa programu bug bounty z kwietnia tego roku, będąca reakcją na zalew zgłoszeń podatności generowanych przez AI.
Pętla, którą domykamy już czwarty raz
To jest czwarty raz w ciągu kilku tygodni, gdy opisujemy AI znajdujące błędy, których wcześniej nie znajdowano. Codex i HTTP/2 Bomb. Glasswing i 10 000 podatności. Xint Code i dwuletni use-after-free w Redisie. Teraz rekord Chrome.
I w tym samym tygodniu — równoległy przypadek, który dopełnia obraz. Startup bezpieczeństwa ogłosił, że autonomiczny agent AI znalazł 21 wcześniej nieznanych podatności w FFmpeg — bibliotece multimedialnej, która napędza niemal wszystkie aplikacje wideo na świecie. Wszystkie 21 znalazło AI, koszt rzędu tysiąca dolarów, dziewięć już z numerami CVE, kod proof-of-concept opublikowany.
Wzorzec się powtarza i jest spójny. Lutowe badanie pokazało, że agent AI potrafi odtworzyć działające exploity dla ponad połowy ze stu realnych błędów jądra Linuksa, bijąc tradycyjny fuzzing. To nie jest seria przypadków — to jest nowa linia bazowa. Znajdowanie błędów stało się tanie.
Zdanie, które jest sednem — i które napisaliśmy w Radarze
Jest jedno zdanie w analizie TheNextWeb, które streszcza całą tę zmianę lepiej niż jakakolwiek liczba: trudny problem się przesuwa. Znajdowanie tych błędów stało się tanie. Triaż zgłoszeń, wydawanie poprawek i doprowadzenie do ich instalacji — nie.
To jest dosłownie teza „bugmageddon", którą postawiliśmy w Radarze #2 jako projekcję na czerwiec: wąskim gardłem bezpieczeństwa przestało być znajdowanie podatności — stało się nim ich naprawianie. Chrome 149 jest tej tezy najczystszym dowodem. 429 znalezionych błędów to triumf strony obrony — ale każdy z nich trzeba striażować, załatać, wydać i doprowadzić do instalacji u miliardów użytkowników. A ta część wciąż spoczywa, jak ujmuje to TheNextWeb przy okazji FFmpeg, na wolontariuszach i cienkiej warstwie ludzkich triażerów, od których teraz oczekuje się dotrzymania tempa maszynom.
To jest asymetria, którą opisujemy od maja. AI po stronie znajdowania działa z prędkością maszyny. Łatanie, dystrybucja i instalacja działają z prędkością ludzi i organizacji. Im lepsze AI do znajdowania, tym szersza ta przepaść — i tym więcej znalezionych, lecz jeszcze niezałatanych błędów krąży w oknie między odkryciem a instalacją.
Dlaczego to dobra wiadomość — i dlaczego niepokojąca
Warto trzymać obie strony naraz, bo to nie jest historia jednoznaczna.
Dobra strona: 429 błędów znalezionych przez stronę obrony to 429 błędów, których nie znajdą jako pierwsi atakujący. Google potwierdził, że żadna z luk w tej aktualizacji nie była aktywnie eksploatowana w momencie wydania. To jest dokładnie sytuacja, o którą chodzi — znaleźć i załatać, zanim ktokolwiek wykorzysta. AI-fuzzing działający na własnej bazie kodu to jeden z najlepszych scenariuszy użycia AI w bezpieczeństwie.
Niepokojąca strona: te same narzędzia są dostępne dla drugiej strony. Skoro AI-fuzzing znajduje 429 błędów w Chrome dla Google'a, znajdzie podobne dla kogoś, kto nie zgłosi ich do programu bug bounty, tylko zachowa na własny użytek. A okno między ujawnieniem łatki a próbą eksploatacji jest wąskie — przy 22 krytycznych lukach analiza łatki przez AI po drugiej stronie może zamienić publiczną poprawkę w mapę ataku, dokładnie jak przy HTTP/2 Bomb, gdzie łatka Apache stała się materiałem dla AI do znalezienia tych samych błędów w IIS, Envoy i Pingora.
Co zrobić
Zaktualizuj Chrome do wersji 149.0.7827.53/54 (Windows, macOS) lub 149.0.7827.53 (Linux) natychmiast. Android — wersja 149.0.7827.59, iOS — 149.0.7827.45.
Chrome zwykle aktualizuje się automatycznie, ale przy 22 krytycznych lukach nie czekaj na automatyczny cykl — wymuś ręcznie przez Menu → Pomoc → Google Chrome — informacje, i zrestartuj przeglądarkę, by aktualizacja się zastosowała. Restart jest konieczny; pobrana, lecz niezainstalowana łatka nie chroni.
Dla organizacji zarządzających flotą: 429 łatek w jednym wydaniu oznacza, że twój cykl testowania przed wdrożeniem dostał nietypowo dużą porcję zmian. Priorytetyzuj 22 krytyczne (sandbox escape, RCE) i nie odkładaj wdrożenia w nieskończoność z powodu rozmiaru — okno między publiczną łatką a analizą przez AT po drugiej stronie jest wąskie.
Szerszy wniosek na przyszłość: rozmiar wydań łatek będzie rósł, nie malał. Jeśli twój proces zarządzania podatnościami zakłada, że „duże wydanie to wyjątek" — to założenie właśnie przestało obowiązywać. Bugmageddon nie jest jednorazowym zdarzeniem, jest nowym stanem normalnym.
Źródła
TheNextWeb — analiza wiążąca rekord Chrome z FFmpeg i tezą o przesunięciu wąskiego gardła: https://thenextweb.com/news/ai-agent-21-zero-days-ffmpeg-chrome-429
PCWorld — szczegóły wydania, lista krytycznych CVE i kwota bug bounty: https://www.pcworld.com/article/3158038/chrome-149-fixes-429-security-flaws-the-most-ever-in-one-update.html
pbxscience — analiza roli AI-fuzzingu i przebudowy bug bounty: https://pbxscience.com/google-chrome-149-fixes-a-record-breaking-429-vulnerabilities-update-now/
Red Secure Tech — kontekst FFmpeg i profil odkryć wewnętrznych vs zewnętrznych: https://www.redsecuretech.co.uk/blog/post/ai-finds-21-ffmpeg-zero-days-chrome-patches-429/1221
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł