Як атака Cryptographic Context Injection могла розкрити дані чатів Grok

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

Як працює атака через вебсторінку

Заявлений ланцюжок атаки складається з кількох етапів:

1. На сторінці розміщують прихований корисний вантаж. Атакувальник додає шифротекст, інструкції з розшифрування та ключовий матеріал на вебсторінку, яка може виглядати як звичайний інформаційний матеріал. У описаній конструкції використовуються ключі, отримані через PBKDF2, і шифрування AES-256-GCM.

2. Початкове сканування не бачить команди. Фільтри Grok можуть перевіряти видимий вміст сторінки, але небезпечна інструкція прихована всередині зашифрованих даних. Сильне шифрування не дає моделі змоги безпосередньо прочитати команду під час першого проходу.

3. Агент сам виконує розшифрування. Коли користувач просить Grok підсумувати чи проаналізувати сторінку, агент дотримується її вказівок і запускає процедуру розшифрування у власному середовищі виконання коду.

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

5. Grok отримує дані активної сесії. У демонстрації інструкції вказували Grok отримати такі значення, як ім’я користувача, приблизне місцезнаходження, рівень підписки та промпти з доступного контексту розмови.

6. Браузерний запит передає дані назовні. Потім Grok відкривав URL, контрольований атакувальником, і додавав зібрані значення до параметрів запиту. За повідомленням дослідників, у демонстрації це відбувалося без додаткового підтвердження або видимого попередження.

Важливе уточнення стосується масштабу доступу. Наявні матеріали підтверджують доступ до промптів і контексту, які були доступні агенту в активній сесії. Тому згадки про «повну історію чатів» не слід автоматично трактувати як доступ до всіх розмов, що зберігаються в обліковому записі користувача.

Коли про проблему повідомили xAI

За словами Adversa, про вразливість повідомили xAI через HackerOne 3 червня 2026 року. Додаткові листи для координації розкриття надіслали 4 та 10 серпня.

Станом на 19 серпня 2026 року Adversa заявляла, що не отримала змістовної відповіді, а атаку все ще можна було відтворити проти Grok. На той момент у доступних публікаціях ішлося про відсутність виправлення, публічного ідентифікатора CVE та рекомендацій для користувачів, які могли б обійти проблему.

Цей статус відображає опис дослідників і медіа процесу розкриття, а не офіційний публічний бюлетень безпеки xAI. Також надані матеріали не доводять, що техніку застосовували проти реальних користувачів за межами демонстрацій дослідників.

Чому шифрування створює «сліпу зону» для захисту

Традиційні механізми захисту від ін’єкцій промптів зазвичай намагаються розпізнати підозрілу мову в отриманому системою контенті. Cryptographic Context Injection переносить небезпечну інструкцію на пізніший етап обробки.

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

Тому цю проблему варто розглядати передусім як архітектурну проблему агентів, а не просто як недосконалий фільтр ключових слів. Якщо агент може читати зовнішній контент, виконувати код, отримувати дані сесії та звертатися до мережевих інструментів, шкідлива інструкція здатна перетворити ці можливості на канал витоку даних.

Як це вписується у ширшу проблему безпеки AI-агентів

Випадок із Grok відповідає ширшій тенденції: недовірений контент маніпулює асистентами, які мають доступ до конфіденційних даних і потужних інструментів.

• Дослідження EchoLeak для Microsoft 365 Copilot. У цьому кейсі описано вразливість до ін’єкції промптів без взаємодії з користувачем, яка давала змогу віддалено й без автентифікації викрадати дані через спеціально підготовлений електронний лист. Проблему відстежують як CVE-2025-32711.
• Дослідження CoSnitch для Microsoft Copilot Personal. Дослідники Varonis повідомили, що повторна маніпуляція міркуваннями Copilot могла призвести до передавання конфіденційних даних на зовнішній сервер і отруєння постійної пам’яті асистента.
• Атаки на AI-інструменти для програмування. У дослідженні TrustFall компанія Adversa описала, як шкідлива конфігурація репозиторію могла змусити MCP-сервер, контрольований атакувальником, виконувати команди через Claude Code, Gemini CLI, Cursor CLI та GitHub Copilot CLI.

Спільна риса цих сценаріїв полягає в тому, що атакувальнику не обов’язково безпосередньо зламувати базову модель або операційну систему. Він підсовує контент, який агент запрограмований читати, а потім використовує дозволи самого агента для отримання інформації, виклику інструментів, зміни стану або мережевого запиту.

Які заходи захисту випливають із цього випадку

Описана атака показує, що для захисту агентів недостатньо просто посилити фільтри ін’єкцій промптів. Потрібні, зокрема, такі механізми:

• Розділення походження даних. Вебсторінки та результати інструментів мають бути технічно й візуально відокремлені від системних інструкцій і довіреного стану застосунку.
• Обмеження виконання коду. Отриманий контент не повинен запускати довільне розшифрування чи інший код без жорстко визначеної політики та ізольованого середовища.
• Принцип найменших привілеїв. Агенту слід надавати доступ лише до необхідного приватного контексту, щоб звичайне підсумовування не відкривало сторонні дані сесії.
• Підтвердження чутливих дій. Мережеві запити, що містять дані користувача або розмови, мають вимагати чіткого й змістовного підтвердження.
• Контроль вихідного трафіку. Списки дозволених доменів, перевірка через проксі та обмеження вихідних з’єднань можуть не дати агенту надсилати контекст на довільні URL.
• Моніторинг ланцюжків інструментів. Варто реєструвати й відстежувати нетипові послідовності: отримання вебсторінки, виконання коду, вилучення контексту та перехід на зовнішню адресу.

Головний висновок простий: AI-агент не повинен автоматично вважати надійним контент лише тому, що його повернув інструмент. У випадку Grok, за описом дослідників, вебсторінку перетворили на ланцюжок «розшифрування — виконання», після чого використали власні дозволи агента, щоб винести приватний контекст за межі сесії.