Уязвимость Adobe Acrobat для Chrome в версиях до 26.5.2.1 позволяла стороннему сайту читать данные из WhatsApp Web без авторизации, без cookie и фактически без участия жертвы после открытия страницы. Для русскоязычной IT-аудитории это неприятное, но полезное напоминание: браузерное расширение с «удобной интеграцией» легко превращается в канал доступа к корпоративной переписке.
О проблеме 22 июля 2026 года сообщил BleepingComputer. Исследователи Guardio Labs назвали цепочку атак HermeticReader, а сама связка уязвимостей получила идентификатор CVE-2026-48294. Сценарий выглядел не как экзотический лабораторный фокус, а как вполне практичная атака: пользователю достаточно было открыть страницу под контролем злоумышленника, если в браузере установлен Adobe Acrobat extension.
Суть сбоя в том, что расширение Adobe позволяло любому сайту маскировать команды под внутренние сообщения самого расширения, включать интеграцию с WhatsApp и перенаправлять привилегированные операции в открытую вкладку WhatsApp Web. В центре схемы оказался Hermes — внутренний движок интеграции между Acrobat и WhatsApp. Обычно он нужен для работы с PDF-файлами, которыми делятся через мессенджер: открыть документ, обработать запрос, вернуть ответ. Но в уязвимой реализации этот же механизм можно было использовать как посредника для команд, работающих с DOM страницы WhatsApp Web.
Guardio описывает атаку как цепочку из трех ошибок, которые вместе давали «неаутентифицированную, однократную, zero-click запись» во внутреннее хранилище расширения с любой веб-страницы. Один из ключевых просчетов: внутренний HTML-ресурс расширения можно было встраивать в iframe на произвольном сайте. Дальше команда передавалась через URL-параметр, обрабатывалась и уходила в service worker расширения, у которого уже были нужные разрешения. Проверки, что команда пришла именно от доверенного контента Adobe, по сути не было. Для расширения, установленного в сотнях миллионов браузеров, это не просто баг, а очень дорогая ошибка в модели доверия.
На практике исследователи показали кражу данных из WhatsApp Web через инъекцию формы в страницу мессенджера. Затем живое содержимое страницы переносилось в элемент формы и отправлялось на сервер злоумышленника. Из-за особенностей браузерной отправки формы и, как утверждают исследователи, отсутствия ограничения form-action в Content Security Policy у WhatsApp Web, браузер мог передать текст уже отрисованной страницы наружу. В результате атакующий получал не абстрактный «доступ к DOM», а вполне читаемый набор пользовательских данных: список чатов, имена контактов, сообщения, имя профиля и содержимое открытого диалога. Важная оговорка: утекали только те сообщения и элементы, которые уже были загружены и отрисованы в интерфейсе. История, до которой браузер еще не докрутился, в этот сценарий не попадала.
Есть и второй вариант злоупотребления, более неприятный с точки зрения последствий, хотя и менее удобный для атакующего. Тот же контроль над DOM позволял подменить QR-код для привязки устройства в WhatsApp. Теоретически это открывало дорогу к захвату аккаунта, если жертва отсканирует подставленный код. Здесь уже появляется трение: пользователя нужно не просто заманить на страницу, а довести до конкретного действия. Но сама возможность показательная. Когда расширение получает привилегированный доступ к интерфейсу стороннего сервиса, граница между «интеграцией» и «удаленным управлением» становится подозрительно тонкой.
Adobe закрыла проблему в версии 26.5.2.3, обновление распространяется автоматически. Уязвимость затрагивала релизы 26.5.2.1 и ниже. По словам ведущего исследователя Guardio Нати Таля, признаков активной эксплуатации CVE-2026-48294 они не увидели. Он также отметил, что команда обнаружила проблему всего через четыре часа после того, как Adobe внесла изменения в расширение и фактически привезла этот баг пользователям. Реакция вендора была быстрой: патч выпустили в течение двух дней, причем на выходных. Для индустрии это, пожалуй, единственная хорошая новость во всей истории.
Но быстрый фикс не отменяет главного вывода. Расширения давно живут в серой зоне между приложением, сайтом и мини-платформой со своими правами, хранилищем, service worker и внутренними страницами. При этом многие команды продолжают относиться к ним как к безобидным «плагинам для удобства». История с WhatsApp Web показывает обратное: если расширение умеет работать с документами, вкладками и DOM другого сервиса, его компрометация автоматически повышает ставки. Для бизнеса это означает риск утечки клиентской переписки, внутренних согласований, HR-коммуникаций и любых PDF-документов, которыми сотрудники перекидываются через мессенджер вместо нормального DLP-контроля.
Для разработчиков и security-команд здесь тоже несколько неприятных, но полезных уроков. Во-первых, модель доверия внутри расширения должна проверяться так же жестко, как серверные API: кто вызывает, откуда, с какими правами и через какой канал. Во-вторых, «внутренняя страница» расширения, доступная через iframe с любого сайта, — это почти просьба о проблемах. В-третьих, интеграции с популярными веб-сервисами нужно тестировать не только на happy path, но и на злоупотребление tab ID, postMessage, storage и service worker. И наконец, если продукт ставится не на тысячи, а на сотни миллионов браузеров, даже короткое окно уязвимости превращается в событие уровня supply-chain для пользовательского слоя браузера.
Пользователям совет один и вполне приземленный: проверить, что Adobe Acrobat extension обновлен как минимум до версии 26.5.2.3. Компания, по данным BleepingComputer, обычно не выпускает security bulletin для потребительских продуктов, но в этом случае проблему признала. На языке эксплуатации это означает простую вещь: лишний раз стоит смотреть не только на список расширений у сотрудников, но и на то, какие из них умеют «помогать» сразу нескольким сервисам. Чем шире такая помощь, тем выше шанс, что в следующий раз утечет не переписка в WhatsApp, а что-нибудь еще более неудобное для утреннего созвона с ИБ и руководством.