В четверг Google сообщила об исправлении 1 072 уязвимостей в Chrome 149 и Chrome 150, выпущенных месяцем ранее. Это больше, чем компания устранила за предыдущие 23 версии браузера вместе взятые. В среду вышло обновление Chrome 151, закрывшее ещё 370 проблем. Из них 349 обнаружили специалисты самой Google, а семь получили критический уровень опасности. Суммарный результат трёх выпусков составил 1 442 исправления.
Такой скачок связан не только с качеством аудита Chrome. Поиск уязвимостей ускоряется экспоненциально, и одним из главных двигателей стали большие языковые модели, LLM. Они позволяют быстрее проверять код и находить ошибки, которые годами не замечали люди. Возникает неприятный перекос: новые проблемы могут регистрироваться быстрее, чем разработчики успевают готовить патчи. По данным американской National Vulnerability Database, NVD, за прошедшую часть 2026 года в базе уже появилось 46 872 уязвимости. За весь 2025 год их было 49 920.
Показательный случай обнаружился в компоненте Chrome Navigation. Уязвимость выхода из песочницы CVE-2026-3545 получила 9,6 балла по шкале CVSS и критический рейтинг. Атака могла заставить браузер читать локальные файлы на компьютере пользователя, то есть обойти границу, которая должна изолировать веб-контент от системы. Google закрыла дыру в начале марта 2026 года. Её нашёл агентный программный комплекс на базе моделей Gemini; ошибка пряталась в исходном коде Chrome больше 13 лет.
Ответом Google на «быстро развивающиеся атаки с применением ИИ» станет более частый выпуск Chrome. Основные версии браузера планируют переводить на двухнедельный цикл, еженедельные обновления безопасности сохранятся, а параллельно компания испытывает режим с двумя защитными релизами в неделю. Ускорение не должно превратить публикацию сведений об ошибках в формальность. Позиция Google сформулирована прямо: «Даже при таком темпе надлежащее публичное раскрытие информации остаётся первостепенным».
Каждая уязвимость, исправление которой попадает в Chrome Stable, должна получить публичное описание независимо от источника: её мог найти сотрудник Google или внешний исследователь. Компания считает такую прозрачность обычной практикой безопасности. Чтобы ручная подготовка документов не задерживала релизы, Google автоматизирует создание примечаний к обновлениям и описаний CVE непосредственно на основе внесённых в код исправлений. Это должно сократить паузу между обнаружением ошибки, выпуском патча и раскрытием технических подробностей.
Даже готовое обновление бесполезно, пока оно не установлено, поэтому Chrome пробует применять патчи без перезапуска браузера. Его многопроцессная архитектура позволяет по очереди заменять работающие в фоне дочерние процессы новыми версиями. В формулировке Google это звучит так: «Используя многопроцессную архитектуру Chrome, динамическое исправление последовательно заменяет фоновые дочерние процессы, такие как Renderer и GPU, обновлёнными исполняемыми файлами прямо во время работы». Если полный перезапуск всё же потребуется, браузер должен бесшовно восстановить сеанс. Пользователю не придётся самому следить, завершилось ли обновление.
Часть этой схемы уже появилась в Chrome 150 для macOS. Приложения в macOS часто продолжают работать после закрытия всех окон. Chrome распознаёт такое состояние без открытых окон и, если обновление ожидает установки, автоматически перезапускается. Момент выбран удачно: браузер ещё запущен, но человек сейчас не работает с его окном. Такой «оппортунистический» перезапуск сокращает задержку установки патча без внезапного обрыва активной сессии.
Отдельная работа идёт против целых семейств ошибок памяти: use-after-free, выхода за границы буфера и других нарушений безопасности памяти. Среду выполнения Chrome укрепляют, чтобы снизить риски старого кода на C++. Одновременно части браузера переносят на языки с безопасной моделью памяти; Google прямо называет Rust одним из вариантов замены. Это долгая переделка, поскольку C++ десятилетиями лежал в основе браузерной архитектуры.
Верхний уровень пользовательского интерфейса Chrome перестраивают с использованием HTML, CSS и TypeScript. Такой подход уменьшает зависимость интерфейса от традиционных фреймворков C++ и вместе с ней площадь для типичных ошибок памяти. Сторонние библиотеки тоже переходят на автоматические конвейеры обновления. Зависимости должны получать свежие версии без долгого ручного ожидания, иначе уже известная уязвимость во внешнем компоненте останется открытой внутри самого браузера.
Google Chrome Security Team описывает практический смысл этой гонки коротко: «Каждая найденная и исправленная ошибка лишает атакующего ещё одной точки опоры». Но исправление требуется быстро выпустить и применить раньше злоумышленника. Поэтому Google одновременно ускоряет релизы, испытывает динамические патчи и автоматические перезапуски, обновляет сторонние зависимости и убирает классы ошибок, связанные с памятью. Задуманная модель Chrome предполагает постоянное получение защиты с минимальным вмешательством пользователя.
Изображение носит иллюстративный характер
Такой скачок связан не только с качеством аудита Chrome. Поиск уязвимостей ускоряется экспоненциально, и одним из главных двигателей стали большие языковые модели, LLM. Они позволяют быстрее проверять код и находить ошибки, которые годами не замечали люди. Возникает неприятный перекос: новые проблемы могут регистрироваться быстрее, чем разработчики успевают готовить патчи. По данным американской National Vulnerability Database, NVD, за прошедшую часть 2026 года в базе уже появилось 46 872 уязвимости. За весь 2025 год их было 49 920.
Показательный случай обнаружился в компоненте Chrome Navigation. Уязвимость выхода из песочницы CVE-2026-3545 получила 9,6 балла по шкале CVSS и критический рейтинг. Атака могла заставить браузер читать локальные файлы на компьютере пользователя, то есть обойти границу, которая должна изолировать веб-контент от системы. Google закрыла дыру в начале марта 2026 года. Её нашёл агентный программный комплекс на базе моделей Gemini; ошибка пряталась в исходном коде Chrome больше 13 лет.
Ответом Google на «быстро развивающиеся атаки с применением ИИ» станет более частый выпуск Chrome. Основные версии браузера планируют переводить на двухнедельный цикл, еженедельные обновления безопасности сохранятся, а параллельно компания испытывает режим с двумя защитными релизами в неделю. Ускорение не должно превратить публикацию сведений об ошибках в формальность. Позиция Google сформулирована прямо: «Даже при таком темпе надлежащее публичное раскрытие информации остаётся первостепенным».
Каждая уязвимость, исправление которой попадает в Chrome Stable, должна получить публичное описание независимо от источника: её мог найти сотрудник Google или внешний исследователь. Компания считает такую прозрачность обычной практикой безопасности. Чтобы ручная подготовка документов не задерживала релизы, Google автоматизирует создание примечаний к обновлениям и описаний CVE непосредственно на основе внесённых в код исправлений. Это должно сократить паузу между обнаружением ошибки, выпуском патча и раскрытием технических подробностей.
Даже готовое обновление бесполезно, пока оно не установлено, поэтому Chrome пробует применять патчи без перезапуска браузера. Его многопроцессная архитектура позволяет по очереди заменять работающие в фоне дочерние процессы новыми версиями. В формулировке Google это звучит так: «Используя многопроцессную архитектуру Chrome, динамическое исправление последовательно заменяет фоновые дочерние процессы, такие как Renderer и GPU, обновлёнными исполняемыми файлами прямо во время работы». Если полный перезапуск всё же потребуется, браузер должен бесшовно восстановить сеанс. Пользователю не придётся самому следить, завершилось ли обновление.
Часть этой схемы уже появилась в Chrome 150 для macOS. Приложения в macOS часто продолжают работать после закрытия всех окон. Chrome распознаёт такое состояние без открытых окон и, если обновление ожидает установки, автоматически перезапускается. Момент выбран удачно: браузер ещё запущен, но человек сейчас не работает с его окном. Такой «оппортунистический» перезапуск сокращает задержку установки патча без внезапного обрыва активной сессии.
Отдельная работа идёт против целых семейств ошибок памяти: use-after-free, выхода за границы буфера и других нарушений безопасности памяти. Среду выполнения Chrome укрепляют, чтобы снизить риски старого кода на C++. Одновременно части браузера переносят на языки с безопасной моделью памяти; Google прямо называет Rust одним из вариантов замены. Это долгая переделка, поскольку C++ десятилетиями лежал в основе браузерной архитектуры.
Верхний уровень пользовательского интерфейса Chrome перестраивают с использованием HTML, CSS и TypeScript. Такой подход уменьшает зависимость интерфейса от традиционных фреймворков C++ и вместе с ней площадь для типичных ошибок памяти. Сторонние библиотеки тоже переходят на автоматические конвейеры обновления. Зависимости должны получать свежие версии без долгого ручного ожидания, иначе уже известная уязвимость во внешнем компоненте останется открытой внутри самого браузера.
Google Chrome Security Team описывает практический смысл этой гонки коротко: «Каждая найденная и исправленная ошибка лишает атакующего ещё одной точки опоры». Но исправление требуется быстро выпустить и применить раньше злоумышленника. Поэтому Google одновременно ускоряет релизы, испытывает динамические патчи и автоматические перезапуски, обновляет сторонние зависимости и убирает классы ошибок, связанные с памятью. Задуманная модель Chrome предполагает постоянное получение защиты с минимальным вмешательством пользователя.
