Google по ошибке раскрыла детали бага, из-за которого уязвимость Chromium позволяет JavaScript продолжать работу даже после закрытия браузера. Для русскоязычной IT-аудитории история неприятна не только из-за масштаба экосистемы Chromium, но и потому, что речь идет не о теоретической дыре: исследовательница проверила эксплойт в мае 2026 года и обнаружила, что проблема все еще воспроизводится в Chrome Dev 150 и Edge 148.
О ситуации сообщает BleepingComputer. Проблему обнаружила исследовательница безопасности Лира Ребейн: еще в декабре 2022 года Google подтвердила ее отчет в Chromium Issue Tracker. Суть бага в том, что злоумышленник может разместить на вредоносной странице Service Worker, например задачу загрузки, которая не завершится штатно. В результате JavaScript может оставаться активным в фоне на устройстве жертвы. Это не означает захват всей системы или доступ к файлам, почте и ОС, но дает атакующему устойчивый исполняемый контекст внутри браузерной среды без повторного визита пользователя на сайт.
Практический сценарий выглядит довольно приземленно, а значит особенно опасно. Пользователь один раз заходит на подготовленную страницу, после чего браузер на базе Chromium может продолжать держать соединение с управляющей инфраструктурой атакующего. По словам Ребейн, в таком виде зараженные браузеры можно использовать для DDoS-атак, проксирования вредоносного трафика и перенаправления запросов на целевые сайты. Иначе говоря, это не «полный взлом компьютера», а тихий способ превратить браузер в послушный узел для сетевых операций. Для корпоративной среды этого уже более чем достаточно: зараженная рабочая станция может стать частью серой инфраструктуры, не оставив пользователю очевидных сигналов.
Отдельный штрих, который делает историю еще менее уютной: проблема затрагивает не один продукт Google, а всю большую семью Chromium-браузеров. В публикации перечислены Google Chrome, Microsoft Edge, Brave, Opera, Vivaldi и Arc. Для бизнеса это означает знакомую, но неприятную картину: формально компании часто диверсифицируют браузеры по отделам, а фактически сидят на одном движке и наследуют одни и те же классы уязвимостей. Для IT-директоров и SecOps-команд это еще одно напоминание, что «мы не на Chrome, у нас Edge» в подобных случаях не является защитной стратегией.
Хронология здесь почти важнее самого бага, потому что показывает сбой не только в коде, но и в процессе. 26 октября 2024 года один из разработчиков Google заметил, что тикет все еще открыт, и назвал проблему серьезной уязвимостью, которой нужен статус-апдейт. 10 февраля 2026 года баг пометили как исправленный, но через несколько минут снова открыли из-за дополнительных вопросов. После этого тикет перевели в процедуру Chrome Vulnerability Rewards Program, а 12 февраля его снова отметили как закрытый и исправленный, хотя патч фактически не был развернут. Автоматическая система даже уведомила Ребейн о выплате вознаграждения в размере 1000 долларов.
Дальше включилась автоматика уже в худшем смысле слова. 20 мая 2026 года с тикета сняли ограничения доступа: по внутренней логике он числился закрытым более 14 недель и якобы исправленным. В тот же день исследовательница перепроверила уязвимость и обнаружила, что она никуда не делась. Более того, в свежем Edge исчезал всплывающий индикатор загрузки, который раньше хотя бы косвенно выдавал аномальную активность. Если раньше пользователь мог хотя бы заметить странное поведение, то теперь, по словам Ребейн, эксплуатация стала еще тише. После этого доступ к тикету снова ограничили, но окно уже открылось достаточно надолго, чтобы технические детали утекли наружу и заметно упростили потенциальную эксплуатацию.
Здесь важен баланс без истерики. Сама Ребейн уточнила Ars Technica, что баг не пробивает браузерные границы безопасности и не дает доступ к письмам, файлам или хостовой операционной системе. Это принципиальная оговорка: речь не о zero-click-компрометации Windows или macOS на уровне системы. Но из этого не следует, что риск малозначим. Если браузер можно незаметно оставить выполнять произвольный JavaScript в фоне после закрытия, этого достаточно для злоупотреблений в сети, нагрузки на каналы, анонимизации чужого трафика и построения распределенной инфраструктуры из ничего, кроме пользовательских визитов на сайт. Масштабировать такую схему до большого ботнета, по оценке исследовательницы, сложнее, чем написать сам эксплойт, но для точечных кампаний и серых сервисов этого может хватить.
Для разработчиков и владельцев продуктов история тоже выглядит как неприятный кейс про доверие к статусам в баг-трекере. Формальная пометка fixed не равна реально доставленному исправлению, а закрытый тикет не гарантирует, что проблема ушла из релизных и дев-веток. Для команд, которые строят внутренние политики безопасности вокруг каналов обновления браузеров, это еще один аргумент проверять не только наличие апдейта, но и его фактическое поведение в своей среде. Для защитников полезный вывод простой: если парк машин массово использует Chromium-браузеры, мониторинг сетевой активности, фоновых процессов браузера и аномальных постоянных соединений снова становится не «параноидальной опцией», а нормальной гигиеной.
Теперь главный вопрос не в том, существует ли уязвимость Chromium, а в том, насколько быстро Google и другие вендоры на ее базе доведут исправление до пользователей после публичной утечки деталей. Эта история бьет сразу по двум болезненным точкам индустрии: монокультуре Chromium и избыточной вере в автоматизированные статусы «исправлено», которые иногда живут своей жизнью дольше, чем сам баг.