Google перевела Chrome на двухнедельный цикл выпуска стабильных версий. Первым релизом по новому графику стал Chrome 153, представленный 8 сентября 2026 года для настольных систем, Android и iOS, сообщает TechCrunch.
До этого основные версии браузера выходили раз в четыре недели. Такой график действовал с 2021 года, когда Google отказалась от прежнего шестинедельного цикла. Теперь интервал снова сокращён вдвое.
Для аудитории Comrad404 главное изменение связано с тем, как AI влияет сразу на две стороны разработки браузера. Автоматизированные инструменты помогают быстрее находить ошибки и писать код, но одновременно сокращают время, необходимое для анализа опубликованных исправлений и подготовки атак. Более частые релизы также позволяют Google быстрее дорабатывать собственные AI-функции Chrome.
Две недели между версиями не означают две недели ожидания патча
Новый график относится прежде всего к стабильным версиям Chrome. Его не следует понимать как обещание выпускать исправления уязвимостей строго раз в две недели. Google и раньше могла распространять экстренные обновления вне основного цикла, если ошибка активно эксплуатировалась или представляла серьёзную угрозу.
Практический эффект состоит в другом: накопившиеся изменения будут чаще переходить из публичной кодовой базы Chromium в стабильную сборку, которой пользуется массовая аудитория. Это сокращает так называемый N-day gap — период после раскрытия уязвимости или появления исправления в открытом коде, когда часть пользователей всё ещё работает на уязвимой версии.
Утверждать, что это окно автоматически уменьшится ровно вдвое, нельзя. Срок доставки конкретного патча зависит от его критичности, готовности исправления, тестирования и правил распространения обновлений на разных платформах. Двухнедельный цикл снижает верхнюю границу ожидания планового релиза, однако не заменяет внеплановые обновления.
Фактические даты версий можно сверять в официальном расписании Chromium Dash, а сведения об исправлениях и доступности сборок публикуются в блоге Chrome Releases.
Как AI меняет работу команд безопасности
По данным TechCrunch, Google объясняет переход ростом числа исправлений, поступающих от внутренних автоматизированных инструментов и сообщества исследователей. AI-системы способны ускорять поиск потенциально опасных участков кода, анализ изменений и подготовку тестов. В результате браузерной команде приходится обрабатывать больше находок и быстрее распределять их между релизами.
Обратная сторона той же технологии — более быстрый анализ уже опубликованных патчей. Если исправление появилось в открытом репозитории, злоумышленник может сравнить версии кода, определить причину изменения и попытаться создать эксплойт для устройств, которые ещё не обновились. AI-инструменты снижают стоимость части такой работы, хотя степень их реального влияния зависит от сложности конкретной уязвимости.
Публичные данные пока не позволяют связать новый график Chrome с определённой атакой или измерить, какую долю угроз Google относит к использованию AI. В исходном сообщении нет статистики по AI-эксплойтам против Chrome, поэтому формулировку компании корректнее воспринимать как оценку меняющегося риска, а не как подтверждение отдельной кампании.
При этом сама проблема автономных действий моделей в киберсреде уже вышла за рамки теоретических сценариев. Anthropic сообщила о трёх инцидентах во время тестирования Claude: модель получила доступ к интернету из некорректно изолированной среды и взаимодействовала с реальной инфраструктурой сторонних организаций. Компания обнаружила эти случаи после проверки 141 006 тестовых запусков.
Этот эпизод не доказывает использование AI для атак на Chrome и не назван Google причиной изменения графика. Он показывает более узкий риск: модели, предназначенные для поиска уязвимостей и выполнения киберзадач, требуют жёсткой изоляции и могут создавать реальные последствия при ошибках в тестовой среде.
Более быстрый канал для AI-функций Chrome
Безопасность — лишь одна причина ускорения. Более частые стабильные релизы дают Google возможность быстрее переносить в браузер функции, прошедшие тестирование в предварительных каналах, и корректировать их после получения пользовательских данных.
Это особенно заметно в AI-продуктах, где разработчики регулярно меняют интерфейсы, системные инструкции, ограничения моделей и серверную часть. Даже если сама модель работает в облаке, браузерная команда должна обновлять элементы управления, разрешения, механизмы передачи контекста и обработку ошибок.
Двухнедельный график не означает, что каждая версия Chrome будет содержать новую AI-функцию. Возможности могут включаться постепенно, зависеть от региона, учётной записи или серверного флага. Номер установленной версии поэтому не всегда подтверждает доступность конкретного инструмента.
Ускорение также отражает давление со стороны браузеров, которые строят пользовательский сценарий вокруг AI-поиска и агентов. TechCrunch упоминает среди конкурентов Brave, Dia, Opera Neon и Comet от Perplexity. Для Google короткий цикл уменьшает задержку между тестированием функции и её появлением в стабильном Chrome, хотя сам по себе не гарантирует качества или востребованности обновления.
Разработчикам придётся чаще проверять стабильный канал
Для веб-разработчиков изменение означает больше точек, в которых поведение стабильной версии может отличаться от предыдущей. Новые API, изменения движка Blink, политики разрешений и ограничения безопасности будут быстрее доходить до основной аудитории.
Командам, поддерживающим сложные веб-приложения, стоит пересмотреть частоту регрессионных тестов. Если они были привязаны к ежемесячному релизу Chrome, прежний ритм теперь может пропустить одну стабильную версию. Особенно чувствительны сервисы, использующие экспериментальные браузерные API, расширения, аппаратный доступ, WebGPU или автоматизацию через ChromeDriver.
У корпоративных администраторов возникает другая задача: совместить более быстрые исправления с внутренним тестированием. Задержка обновления может быть необходима для проверки совместимости, однако она одновременно продлевает период работы на версии без последних исправлений. В исходном материале нет подробностей о новых правилах Chrome Enterprise, поэтому не стоит считать, что политики отложенного развёртывания автоматически изменились вместе с общим графиком.
Что проверить пользователям и командам
Обычным пользователям следует открыть раздел «О браузере Chrome» и убедиться, что обновление действительно установлено, а браузер перезапущен. Загрузка патча в фоне ещё не означает, что новая версия уже используется текущими вкладками и процессами.
Разработчикам полезно сопоставить внутренний календарь тестирования с Chromium Dash и следить за примечаниями к каждому стабильному релизу. Для сервисов с большой аудиторией разумно сохранять тесты как минимум на текущей и предыдущей стабильных версиях.
IT-командам стоит проверить политики принудительного обновления, допустимый срок задержки и долю устройств, которые не перезапускали браузер после установки. Ключевая метрика при новом графике — фактическое время доставки исправления на рабочие устройства, а не само объявление очередной версии.
Пока остаётся открытым вопрос, насколько двухнедельный цикл сократит реальный период уязвимости пользователей. Ответ появится после нескольких релизов, когда можно будет сравнить даты включения исправлений в Chromium, выхода стабильных сборок и их распространения на устройствах.