Про результати Google розповіла 30 липня 2026 року, пояснивши, що внутрішні інструменти на основі штучного інтелекту стали важливою частиною пошуку та усунення вразливостей у Chrome .
ШІ використовується не лише для пошуку підозрілих фрагментів коду. Google поступово залучає моделі на різних етапах життєвого циклу вразливості:
На початку 2026 року Google розробила спеціальне агентське середовище з Gemini. Компанія заявляє, що воно шукає вразливості ефективніше й генерує менше хибних спрацьовувань, ніж попередні підходи . У багатoагентному процесі одні моделі можуть готувати патчі, інші — критикувати їх або перевіряти коректність перед внесенням змін до проєкту .
Це частина ширшої стратегії Google. У жовтні 2025 року DeepMind представила CodeMender — ШІ-агента, який автоматично знаходить і виправляє вразливості, а також може переписувати код, щоб запобігати цілим класам помилок . 21 липня 2026 року компанія також оголосила про Gemini 3.5 Flash Cyber — спеціалізовану модель для швидкого виявлення, перевірки та виправлення вразливостей. На першому етапі вона доступна урядам і довіреним партнерам через обмежену пілотну програму .
Найбільш показовим результатом став баг обходу пісочниці, який непомітно залишався в коді Chrome понад 13 років .
Вразливість отримала ідентифікатор CVE-2026-15119. Це помилка типу race condition у реалізації GetUserMedia. За певних умов зловмисник, який уже отримав контроль над процесом рендерингу, міг би вийти за межі обмеженого середовища браузера та змусити його прочитати локальні файли .
Пісочниця Chrome ізолює вебсторінки від операційної системи, тому її обхід вважається особливо небезпечним. Така вразливість може стати проміжною ланкою для виконання коду поза захищеним середовищем браузера. Для порівняння, за одну з попередніх вразливостей обходу пісочниці — CVE-2025-4609 — дослідник отримав винагороду Google у розмірі 250 000 доларів .
Google зазначила, що CVE-2026-15119 не виявили під час попередніх людських перевірок коду. Саме цей випадок, за словами компанії, продемонстрував потенціал ШІ-пошуку вразливостей .
Зростання кількості знайдених проблем змушує Google скорочувати проміжок між виявленням багу та доставкою виправлення користувачам. Компанія оголосила про кілька змін у графіку оновлень:
Швидший графік стосуватиметься стабільних версій Chrome для настільних і мобільних платформ. Розробницькі канали Dev і Canary працюватимуть за своїми поточними розкладами .
Часті оновлення створюють очевидну незручність: браузер просить закрити вкладки та перезапуститися. Щоб цього уникнути, Google працює над технологією, яку називає dynamic patching або dynamic matching.
Ідея полягає в тому, щоб замінювати фонові дочірні процеси Chrome — зокрема Renderer і GPU — на оновлені бінарні компоненти без повного перезапуску браузера. Google прагне, щоб у більшості випадків користувачеві не доводилося перезапускати Chrome вручну .
Компанія також повідомила, що починаючи з Chrome 150 на macOS браузер може автоматично перезапуститися для встановлення очікуваного оновлення, якщо він працює у фоновому режимі й не має відкритих вікон . Водночас повноцінне динамічне накладання патчів поки що залишається напрямом розробки, а не універсально доступною функцією .
29 липня 2026 року Google випустила стабільний Chrome 151 для Windows, macOS і Linux. Оновлення виправляє 370 вразливостей .
| Рівень небезпеки | Кількість |
|---|---|
| Критичний | 7 |
| Високий | 71 |
| Середній | 170 |
| Низький | 122 |
Серед критичних проблем:
У Chrome 151 Google також почала переводити XML-парсер на реалізацію мовою Rust із захистом від помилок керування пам’яттю. Зміна стосується поширених сценаріїв, де не потрібен XSLT, і має усунути потенційні проблеми з пошкодженням пам’яті без втрати сумісності з вебстандартами .
Для більшості людей нічого налаштовувати не потрібно: Chrome оновлюється у фоновому режимі. Однак із вересня браузер почне отримувати основні релізи помітно частіше — кожні два тижні, починаючи з Chrome 153 8 вересня 2026 року .
Користувачам варто не відкладати перезапуск браузера, коли оновлення вже завантажене, а також перевірити версію Chrome, якщо браузер давно не закривався. Очікується, що динамічне накладання патчів згодом зменшить кількість вимушених перезапусків.
Випадок Chrome показує, як ШІ змінює не лише швидкість пошуку багів, а й саму економіку кібербезпеки. Моделі можуть цілодобово аналізувати великі кодові бази, порівнювати зміни, готувати патчі та перевіряти їх — завдання, для яких людській команді потрібні значно більші ресурси .
Водночас фінальне рішення про внесення виправлень залишається критично важливим: автоматично згенерований патч потрібно перевірити, протестувати та безпечно доставити користувачам. Для Chrome Google поєднує ці перевірки з частішими релізами, щоб скоротити час, протягом якого відома вразливість може залишатися невиправленою.