Google за два крупных релиза Chrome подряд исправил 1072 уязвимости. Это больше, чем компания закрыла суммарно в предыдущих 23 стабильных версиях браузера. Для ИБ-команд и ИТ-руководителей новость неприятная, но полезная: скорость поиска багов резко выросла, и старый ритм обновлений уже не поспевает за этим потоком.
Речь идет не о разовом всплеске в отчете ради красивой цифры. Google прямо пишет, что большие языковые модели ускорили поиск, проверку и исправление уязвимостей. И если раньше узким местом был сам поиск ошибок, то теперь проблема сместилась в доставку патча до компьютера пользователя.
Почему число исправлений резко выросло
В официальном отчете Chrome Security Team от 30 июля 2026 года сказано: в релизах Chrome 149 и 150 компания исправила 1072 проблемы безопасности. По данным Google, это больше, чем во всех предыдущих 23 крупных релизах вместе. Команда объясняет скачок не только внешними отчетами исследователей, но и собственными инструментами на базе ИИ для поиска, сортировки и подготовки исправлений.
Один из показательных примеров Google приводит отдельно: в начале 2026 года внутренний агентный контур на базе Gemini нашел sandbox escape, который позволял скомпрометированному процессу рендеринга добраться до локальных файлов пользователя. По словам Google, эта ошибка прожила в кодовой базе больше 13 лет. Для зрелого продукта масштаба Chrome это, мягко говоря, отрезвляющая цифра.
Google меняет график обновлений
На фоне такого потока находок компания ускоряет выпуск исправлений. Google уже переводит Chrome на двухнедельный цикл крупных версий с еженедельными обновлениями безопасности между ними. Параллельно команда тестирует еще более плотный режим: два выпуска с исправлениями безопасности в неделю.
Логика простая. Как только исправление попадает в открытый код и выходит в стабильный канал, у злоумышленников начинается окно для обратного анализа. В Google называют это риском N-day-атак: уязвимость уже закрыли, но пользователь или компания еще не применили обновление. Чем дольше этот разрыв, тем выше шанс, что баг успеют превратить в рабочий инструмент атаки.
Патчи хотят ставить почти без участия пользователя
Google пытается сократить этот разрыв не только частотой релизов, но и способом их применения. Компания разрабатывает dynamic patching: механизм, который должен обновлять фоновые дочерние процессы Chrome, включая Renderer и GPU, без полного перезапуска браузера. Это пока не массовая функция, а направление разработки, но вектор понятен: чем меньше пользователь замечает обновление, тем выше шанс, что патч реально дойдет до системы вовремя.
Часть этой логики уже работает на macOS в Chrome 150. Если браузер видит ожидающее обновление в состоянии без открытых окон, он может автоматически перезапуститься в фоне. Для обычного пользователя это удобно. Для корпоративной среды важнее другое: меньше шансов неделями жить с уже скачанным, но не примененным исправлением.
Что это меняет для компаний
Для российского и СНГ-рынка здесь нет экзотики. Браузер давно стал рабочим интерфейсом для CRM, SaaS, админок, внутренних панелей и облачных офисов. Поэтому обновление Chrome теперь стоит рассматривать не как задачу пользователя, а как часть управляемого процесса безопасности. Google прямо советует администраторам включать политику принудительного напоминания о перезапуске, использовать Extended Stable Channel там, где нужен дополнительный цикл проверки, и отслеживать версии браузера через Chrome Enterprise.
Если коротко, рынок входит в режим почти непрерывного обновления браузера. Выиграют те команды, у которых патч-менеджмент не упирается в ручные письма сотрудникам и надежду, что кто-то сам нажмет кнопку обновления.
Следующий логичный шаг для Google — довести dynamic patching до рабочего состояния и еще сильнее сократить время между исправлением бага и его применением на устройстве.
Источники: , , .