5 августа 2026 года исследователь PortSwigger Гарет Хейес заявил на Black Hat USA, что атаки через CSS уже позволяют вытаскивать данные из веб-почты и даже собирать ввод пользователя без JavaScript и вложений. Для рынка, который привык искать зло в скриптах, макросах и подозрительных файлах, это плохая новость. Для русскоязычных команд, поддерживающих почтовые интерфейсы, корпоративные порталы и фронтенд с пользовательским HTML, сигнал предельно практичный: проверять надо не только код, но и стили.
Как пишет Dark Reading, Хейес пришёл к теме не из академического упражнения, а из почти бытового эксперимента: разбирался с дизайном собственного сайта и увидел, насколько далеко уехал современный CSS. По его словам, язык, который долго считали обслуживающим слоем для вёрстки, теперь по возможностям местами напоминает упрощённый язык программирования. В паре с HTML этого уже достаточно, чтобы без единой строчки JavaScript построить рабочий кейлоггер и канал для утечки конфиденциальных данных. И речь не о красивой теории: исследователь говорит, что нашёл уязвимости в крупных, хорошо известных сервисах и вынес результаты на Black Hat USA 2026 в Лас-Вегасе.
Это неприятно ещё и потому, что CSS исторически выпадал из центра внимания защитников. Веб и почтовые клиенты годами учились отсекать вредоносные вложения, блокировать активный контент, обрезать подозрительный JavaScript, фильтровать события, ссылки и другие привычные индикаторы атаки. Но CSS в этой модели оставался чем-то вроде «декора», хотя браузеры последовательно добавляли ему новые функции. Хейес формулирует проблему без дипломатии: чем богаче становятся CSS и HTML, тем шире поверхность атаки. Атаки через CSS требуют больше изобретательности, чем классические фишинговые письма, но именно поэтому они легко проходят мимо устоявшихся правил фильтрации.
Ключевой поворот здесь в том, что атакующему не обязательно запускать код в привычном смысле слова. Если защитная логика опирается на принцип «нет скрипта, нет риска», она уже устарела. Для корпоративной почты это особенно болезненно: браузерный интерфейс давно стал рабочим местом, где рядом с письмом живут поиск, список диалогов, адресные поля, кнопки действий, предпросмотры и другие элементы страницы. Если стили из сообщения способны влиять на это окружение шире, чем задумано, проблема выходит за рамки одного письма и начинает бить по границам доверия всей страницы.
Сам пользователь здесь почти бессилен. Хейес прямо говорит: отключить CSS нельзя. Если человек открывает письмо в веб-интерфейсе, он уже играет по правилам платформы. Поэтому основная ответственность ложится на вендора сервиса. Минимальный набор защиты звучит не как футуризм, а как базовая гигиена: изолировать письмо от остальной страницы, не давать стилям «протекать» наружу, держать жёсткий белый список допустимых CSS-конструкций и следить за тем, чтобы сообщение не ломало границы доверия интерфейса. Всё это скучно до первого инцидента, а после инцидента обычно внезапно становится приоритетом квартала.
Есть и более точечные меры. Хейес советует использовать image proxy, чтобы внешние изображения в письмах загружались не напрямую с удалённого адреса, а через прокси самой платформы. Это не чинит весь класс проблем, но снижает часть рисков, связанных с трекингом и побочными каналами утечки. Важнее другое: в своём исследовании он наткнулся не на единичный эффектный баг для сцены Black Hat, а на целый набор проблем. Среди них: hijacking-баги, более продвинутые техники атаки и уязвимости в самих веб-почтовых платформах. Поверхность риска уже живая, а не обсуждается в будущем времени.
Отдельный сюжет: реакция вендоров. По словам исследователя, часть компаний ответила быстро и прозрачно. Часть сначала отвергала сообщения об уязвимостях, а затем молча выкатывала исправления, не признавая проблему публично. Для инженерных команд это тревожный маркер: если поставщик продукта всё ещё воспринимает CSS как безопасный оформительский слой, то и модель угроз у него, скорее всего, собрана по лекалам десятилетней давности. Не самый лучший признак для сервиса, через который проходят коммерческие предложения, резюме, счета, юридические документы и доступ к другим системам.
Уязвим этот класс проблем не только для почтовых провайдеров. Любой продукт, который рендерит пользовательский HTML внутри сложного веб-интерфейса, получает похожую задачу: как дать достаточно богатое отображение и не открыть путь к утечке данных из соседних компонентов. Для разработчиков это повод пересматривать санитайзеры и правила рендеринга. Для продуктовых команд это причина заранее закладывать время на изоляцию писем и ограничение стилей, даже если пользователи будут недовольны потерянной «красотой» рассылок. Для IT-директоров и SecOps вывод совсем приземлённый: такие вещи пора проверять в аудитах отдельно, а не считать автоматом закрытыми одной лишь защитой от XSS.
Главный вывод из этой истории неприятно прост: атаки через CSS перестают выглядеть экзотикой для конференционных слайдов и становятся нормальным кандидатом в следующий класс реальных инцидентов. Браузеры продолжают усложнять язык стилей, веб-почта остаётся толстым приложением, а граница между «оформлением» и «логикой» расползлась уже давно. Если рынок не начнёт относиться к CSS как к полноценной части поверхности атаки, следующую проблему в почте будут искать не в исполняемом файле и не в скрипте, а в «безобидном» оформлении письма.