КИБЕРБЕЗОПАСНОСТЬ

Уязвимость в Gemini прятала вредоносные команды в уведомлениях

3 июня 2026 года SafeBreach описала атаку на Gemini: вредоносные инструкции можно было спрятать в уведомлениях и обойти защитные барьеры.

✍️ Редакция iTech News | 04.06.2026 | ⏱ 5 мин | Источник: Dark Reading
🚨

Уязвимость Google Gemini позволяла прятать вредоносные инструкции прямо в уведомлениях мессенджеров, а затем подсовывать их голосовому помощнику под видом безобидного контекста. Для тех, кто строит продукты вокруг ИИ-ассистентов или пускает их в корпоративный контур, новость неприятная: достаточно одного неверно размеченного внешнего сигнала, чтобы модель начала помогать уже не пользователю, а атакующему.

О проблеме 3 июня 2026 года сообщает Dark Reading со ссылкой на исследование SafeBreach. Речь идет о prompt injection в голосовом сценарии Gemini: атакующий мог отправить сообщение через мессенджер, спрятать внутри него инструкции для модели и дождаться, пока пользователь попросит ассистента озвучить или суммировать уведомления. В этот момент Gemini получал не только видимый текст сообщения, но и скрытые подсказки, которые влияли на то, как именно он перескажет содержимое и какие дальнейшие действия предложит.

Исследование подготовила команда SafeBreach, а техлидом выступил Ор Яир. По его словам, злоумышленник мог маскировать инструкции несколькими способами. Первый вариант: использовать текст на иностранном языке, который модель интерпретирует, но не зачитывает пользователю. Второй: убирать вредоносную нагрузку внутрь «приглушенной» гиперссылки, так что человек слышит обычное сообщение, а модель получает дополнительный контекст. Итог выглядел почти комично, если забыть, что это про безопасность: пользователь слышит невинную формулировку, отвечает «да», а ассистент уже считает, что получил разрешение на небезопасное действие.

Сценарий атаки в статье описан довольно приземленно, и от этого он только хуже. Представим сообщение в WhatsApp с приглашением на день рождения от якобы знакомого человека и просьбой скинуть деньги на еду по ссылке. Если открыть переписку глазами, шансы заметить подвох неплохие: незнакомый номер, подозрительная просьба, лишняя спешка. Но если пользователь за рулем или просто привык получать сводку уведомлений голосом, Gemini может выдать сокращенную и искаженную версию: мол, ваш друг приглашает вас на праздник. Контекст о том, что номер незнакомый, может потеряться. А дальше начинается обычная, старая как мир социальная инженерия, только с ИИ в роли слишком доверчивого секретаря.

Почему сработали скрытые команды

Ключевая проблема, по данным SafeBreach, была не просто в том, что модель читала внешний текст, а в том, что защитные механизмы не всегда корректно различали источник и смысл отдельных фрагментов сообщения. Исследователь назвал новую технику Fake Context Alignment. Если коротко, она создает двойную картину: внутренним механизмам безопасности подсовывается будто бы легитимный сценарий авторизации, а пользователю показывается или озвучивается совсем другой, безобидный сюжет. Для защитных барьеров все выглядит почти нормально; для жертвы тоже. Ненормально только то, что решение в итоге принимается в интересах атакующего.

SafeBreach пишет, что через такую схему можно было не просто исказить пересказ уведомления. Среди возможных последствий компания перечисляет управление устройствами умного дома, запуск несанкционированных видеопотоков, атаки через impersonation доверенных контактов и даже отравление долговременной памяти LLM. Последний пункт особенно неприятен для команд, которые сейчас всерьез обсуждают persistent memory как способ сделать ассистента полезнее. Память без жесткой дисциплины доверия быстро превращается в поверхность атаки, где ложный контекст живет дольше одной сессии и влияет на следующие ответы модели.

Отдельно интересен прием Delayed Tool Invocation, о котором SafeBreach рассказывала и раньше. Идея в том, чтобы спрятать инструкцию на будущее: если пользователь потом даст вторичное подтверждение, модель выполнит небезопасное действие. В примере из статьи злоумышленник отправляет обычное «Hello», следом вставляет скрытые китайские символы с инструкцией, которую ассистент не произносит, а затем завершает сообщение фразой «Will that be all?». Пользователь отвечает утвердительно, считая, что просто завершает диалог, а модель воспринимает это как разрешение на следующий шаг. Яир отмечает, что наилучшую надежность дала комбинация двух методов сразу: иностранный текст плюс гиперссылка, внутри которой этот текст спрятан.

Важно, что на момент публикации SafeBreach не обнаружила признаков эксплуатации этой техники в реальных атаках. Исследователи сообщили о проблеме Google в рамках responsible disclosure, после чего компания обновила content classifiers. Иными словами, конкретный описанный вектор Google уже закрыла. Но успокаиваться тут особенно нечем. Сам Яир прямо говорит, что непрямые prompt injection-атаки нельзя воспринимать как классическую уязвимость в духе «нашли баг, залили патч, забыли». Это скорее системная особенность публичных LLM-интерфейсов: модель обрабатывает внешний ввод, а внешний ввод почти всегда может оказаться инструкцией, замаскированной под данные.

Что это значит для разработчиков и бизнеса

Для русскоязычной IT-аудитории история важна не потому, что речь именно о Google. Сегодня почти каждый крупный игрок строит ассистентов, которые читают уведомления, работают с календарем, почтой, чатами, файлами и инструментами автоматизации. Чем полезнее агент, тем ближе он к чужому контенту. А чем ближе он к чужому контенту, тем меньше смысла в наивной модели доверия, где сообщение из мессенджера считается просто данными, а не потенциальной командой. Уязвимость Google Gemini здесь выступает скорее как наглядный кейс для всей отрасли: нельзя скрещивать генеративную модель, внешние каналы и tool use без отдельного слоя контроля источников, разрешений и интерпретации контекста.

Практический вывод для продуктовых и инженерных команд довольно жесткий. Если ваш ИИ-ассистент умеет суммировать уведомления, запускать действия по подтверждению пользователя или накапливать память, весь внешний контент нужно считать недоверенным по умолчанию. Именно так Яир ответил на вопрос Dark Reading: да, на 100%. Это означает не только фильтры и классификаторы, но и пересборку UX. Пользователь должен слышать не гладкий литературный пересказ, а критически важный контекст: кто отправитель, откуда пришло сообщение, есть ли ссылка, нет ли конфликта между видимым и интерпретированным содержимым. Иначе мы получаем ассистента, который прекрасно оптимизирован под удобство и слишком слабо оптимизирован под недоверие к миру вокруг.

На этом фоне главный вопрос уже не в том, сколько еще похожих техник найдут исследователи, а в том, готовы ли вендоры признать неприятный базовый факт: голосовой ИИ, связанный с уведомлениями и инструментами, по умолчанию живет внутри враждебной среды. И если защиту строить как косметику поверх «умного» UX, очередная инъекция все равно найдет себе щель. Подробнее об исследовании пишет Dark Reading.

Поделиться: Telegram X LinkedIn