Как атака Cryptographic Context Injection обходит защиту Grok

Исследователь Adversa AI Рони Утевский сообщил об атаке, получившей название Cryptographic Context Injection. Она относится к непрямой prompt-инъекции и краже данных через инструменты ИИ-агента.

Для запуска атаки пользователю не нужно вводить вредоносную команду. Достаточно попросить Grok пересказать или проанализировать специально подготовленную веб-страницу. В ходе тестов Adversa агент смог расшифровать инструкции, контролируемые атакующим, получить сведения из активного диалога и отправить их на внешний сервер без заметного запроса на подтверждение.

В чём заключалась проблема

Сама криптография AES-256-GCM не была взломана. Уязвимость возникала на стыке нескольких возможностей Grok: проверки содержимого, выполнения кода и веб-навигации.

Вредоносная страница содержала зашифрованную команду, инструкции по её расшифровке и необходимые ключевые данные. На первом этапе защиты Grok видел не открытый текст, а шифротекст, поэтому не мог распознать опасную команду напрямую. Затем агента побуждали запустить процедуру расшифровки в среде выполнения Python или другого кода. Расшифрованный текст возвращался модели как результат работы инструмента — и мог восприниматься иначе, чем недоверенная инструкция, размещённая непосредственно на странице.

Adversa сообщила о тестировании метода против Grok 4.5 Fast на сайте grok.com. В отдельном описании эксперимента говорится, что атака сработала в 40% из 20 попыток, проведённых в период с июня по август 2026 года. Это результат в среде исследователей, а не гарантия успешной атаки в каждом сеансе Grok.

Как работала атака через веб-страницу

Заявленная цепочка выглядела следующим образом:

1. На страницу помещался скрытый payload. Атакующий размещал на сайте шифротекст, инструкции по расшифровке и ключевой материал. В описанной схеме использовались PBKDF2 для формирования ключа и шифрование AES-256-GCM.

2. Первичная проверка не видела команду. Фильтры Grok могли анализировать видимое содержимое страницы, но опасная инструкция находилась внутри зашифрованных данных. Надёжное шифрование не позволяло модели прочитать её при первом просмотре.

3. Агент выполнял расшифровку. После просьбы пользователя пересказать или проанализировать страницу Grok следовал размещённым на ней указаниям и запускал процедуру расшифровки в среде выполнения кода.

4. Команда возвращалась в контекст агента. Расшифрованный текст появлялся как результат операции инструмента. Так возникала проблема с происхождением данных: содержимое, полностью контролируемое атакующим, переходило из недоверенной веб-страницы в контекст, который агент мог считать рабочим результатом инструмента.

5. Grok извлекал данные текущего сеанса. В демонстрации расшифрованная инструкция предписывала получить имя пользователя, примерное местоположение, уровень подписки и промпты из доступного контекста разговора.

6. Данные передавались через веб-запрос. Затем Grok открывал URL, контролируемый атакующим, и помещал собранные значения в параметры запроса. В представленном доказательстве концепции дополнительного подтверждения или видимого предупреждения не появлялось.

Важное ограничение

Доступные материалы подтверждают извлечение промптов и контекста, предоставленных агенту в активном сеансе. Формулировку «полная история чатов» не следует автоматически понимать как доступ ко всем разговорам, сохранённым в аккаунте пользователя. Речь идёт о данных, которые Grok сделал доступными агенту в конкретном контексте.

Когда Adversa сообщила об атаке xAI

По данным Adversa, уязвимость передали xAI через программу HackerOne 3 июня 2026 года. Исследователи также направили последующие сообщения для координации раскрытия 4 и 10 августа.

По состоянию на 19 августа 2026 года Adversa заявляла, что не получила содержательного ответа и по-прежнему могла воспроизвести атаку против Grok. В публикациях того времени также указывалось, что исправление не было развёрнуто, публичный идентификатор CVE отсутствовал, а пользовательского обходного решения не было.

Это описание отражает позицию исследователей и публикации о процессе раскрытия, а не официальное уведомление xAI о безопасности. Представленные материалы также не доказывают, что метод применялся против реальных пользователей за пределами исследовательских демонстраций.

Почему шифрование стало слепой зоной для защиты

Многие средства защиты от prompt-инъекций ищут подозрительные формулировки в содержимом, которое ИИ получает извне. Cryptographic Context Injection переносит опасную команду на более поздний этап обработки.

Модели не нужно понимать вредоносную инструкцию при первом сканировании страницы. Ей достаточно выполнить внешне полезное указание — например, запустить процедуру расшифровки — в среде, которая считается доверенной. Команда становится читаемой уже после выполнения кода, когда агент может иметь доступ к приватному контексту и право обращаться к браузеру или сетевым инструментам.

Поэтому проблему правильнее рассматривать как архитектурный риск ИИ-агента, а не просто как неудачу фильтра по ключевым словам. Если агент способен читать внешние материалы, выполнять код, обращаться к данным сеанса и делать сетевые запросы, вредоносная инструкция может превратить эти полномочия в канал утечки.

Как этот случай вписывается в общую проблему безопасности ИИ-агентов

История с Grok продолжает более широкий ряд атак, в которых недоверенный контент манипулирует ассистентом, имеющим доступ к чувствительной информации и мощным инструментам.

• EchoLeak в Microsoft 365 Copilot. Исследование описало уязвимость prompt-инъекции без действий со стороны пользователя: специально подготовленное письмо могло привести к удалённой неаутентифицированной краже данных через Microsoft 365 Copilot. Уязвимость отслеживается как CVE-2025-32711.
• CoSnitch в Microsoft Copilot Personal. Исследователи Varonis сообщили, что последовательная манипуляция рассуждениями Copilot могла привести к отправке чувствительных данных на внешний сервер и отравлению постоянной памяти ассистента.
• Атаки на ИИ-инструменты для разработки. В исследовании TrustFall компания Adversa описала, как вредоносная конфигурация репозитория может заставить MCP-сервер, контролируемый атакующим, выполнять команды через Claude Code, Gemini CLI, Cursor CLI и GitHub Copilot CLI.

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

Какие меры защиты нужны

Описанная атака показывает, что одних фильтров prompt-инъекций недостаточно. Важны следующие меры:

• Разделение происхождения данных. Содержимое веб-страниц и результаты инструментов должны быть технически и визуально отделены от системных инструкций и доверенного состояния приложения.
• Ограничение выполнения кода. Полученные извне материалы не должны запускать произвольную расшифровку или другой код без строгой политики и изолированной среды.
• Принцип минимальных привилегий. Агенту следует предоставлять только необходимый приватный контекст, не позволяя обычной задаче по пересказу раскрывать сведения из других частей сеанса.
• Подтверждение чувствительных действий. Сетевые запросы, содержащие пользовательские данные или содержимое разговора, должны требовать явного и понятного согласия.
• Контроль исходящего трафика. Списки разрешённых доменов, прокси-проверка и ограничения egress должны блокировать отправку контекстных данных на произвольные URL.
• Мониторинг цепочек действий. Необычные последовательности — загрузка страницы, выполнение кода, извлечение контекста и переход на внешний адрес — должны журналироваться и вызывать предупреждения.

Главный вывод прост: результат работы инструмента не становится доверенным автоматически. В описанном случае веб-страница превратилась для Grok в цепочку «расшифровать — выполнить — отправить», а затем использовала собственные полномочия агента, чтобы вывести приватный контекст за пределы сеанса.