Уязвимость в Antigravity IDE от Google
Исследователи в области кибербезопасности обнаружили и помогли устранить серьёзную уязвимость в интегрированной среде разработки (IDE) Antigravity от Google. Проблема позволяла злоумышленникам выполнять произвольный код — но уже закрыта разработчиками. Разберёмся, в чём была суть угрозы и какие уроки можно извлечь.
Как работала уязвимость
Слабое место объединяло две особенности Antigravity:
Это позволяло обходить «Строгий режим» (Strict Mode) — специальную настройку безопасности, которая:
ограничивает доступ к сети;
запрещает запись за пределы рабочей области;
запускает все команды в изолированной среде (песочнице).
Механизм атаки
Ключевым элементом атаки был флаг -X (exec-batch), который можно было внедрить через параметр Pattern в инструменте find_by_name:
Параметр Pattern предназначен для ввода шаблона поиска файлов — он запускает поиск файлов и каталогов через команду fd с помощью find_by_name.
Из‑за слабой проверки вводимых данных этот параметр передавал данные напрямую в команду fd, минуя ограничения «Строгого режима».
Если задать значение Pattern как -Xsh, команда fd передавала найденные файлы в sh для выполнения в виде скриптов оболочки.
Таким образом злоумышленник мог:
разместить вредоносный скрипт;
запустить его через обычный, на первый взгляд, поиск;
всё это — без дополнительных действий пользователя после внедрения вредоносной команды.
Косвенная инъекция подсказок
Атаку можно было запустить и без взлома учётной записи пользователя. Схема выглядела так:
Пользователь загружал, казалось бы, безобидный файл из ненадёжного источника.
Файл содержал скрытые комментарии, контролируемые злоумышленником.
Искусственный интеллект (ИИ)‑агент выполнял эти инструкции — размещал и запускал эксплойт.
Реакция Google
После ответственного раскрытия информации 7 января 2026 года Google устранила уязвимость к 28 февраля.«Инструменты, предназначенные для ограниченных операций,
становятся векторами атак, если их входные данные не проверяются строго, — отметил исследователь безопасности компании Pillar Security Дэн Лисичкин. — Модель доверия, лежащая в основе предположений о безопасности, согласно которой человек заметит что‑то подозрительное, не работает, когда автономные агенты выполняют инструкции из внешнего контента».
Похожие уязвимости в других ИИ‑инструментах
Проблема с инъекциями подсказок затронула и другие ИИ‑сервисы. Рассмотрим основные случаи:
1. Comment and Control
Атака, использующая комментарии в GitHub для кражи API‑ключей и токенов через:
Уязвимы оказались:
2. Отравление памяти Claude Code (обнаружено Cisco)
Злоумышленники могли отравить память ИИ‑агента, сохранив вредоносные изменения на всех проектах и сессиях — даже после перезагрузки системы. Атака использовала цепочку поставок ПО для внедрения вредоносного кода.
3. NomShub в Cursor
Критическая цепочка уязвимостей позволяла вредонозному репозиторию тайно захватывать компьютер разработчика через:
косвенную инъекцию подсказок;
выход из песочницы парсера команд;
встроенный удалённый туннель Cursor.
Последствия: постоянный, необнаруживаемый доступ к оболочке при открытии репозитория в IDE.
4. ToolJack
Новая атака позволяла локальному злоумышленнику манипулировать восприятием ИИ‑агента об окружающей среде, искажая «истину» инструмента для создания нежелательных последствий:
5. ShareLeak (CVE‑2026‑21520) и PipeLeak
Уязвимости в Microsoft Copilot Studio и Salesforce Agentforce позволяли злоумышленникам извлекать конфиденциальные данные через внешние формы SharePoint или простые лиды из форм.
6. Claudy Day
Цепочка из трёх уязвимостей в Claude позволяла с одного клика:
Схема атаки:
скрытые инструкции встраивались в специально созданную ссылку Claude;
ссылка маскировалась через открытый редирект на claude.com;
запускалась через безобидное на вид объявление в Google Ads.
7. Обман Claude в GitHub Actions
Исследователи Manifold Security показали, как рабочий процесс GitHub Actions с Claude («claude‑code‑action») можно обмануть, чтобы одобрить и объединить pull request с вредоносным кодом. Для этого достаточно двух команд конфигурации Git, подменяющих личность доверенного разработчика.
Выводы и рекомендации
Обнаруженные уязвимости показывают:
ИИ‑агенты, обрабатывающие ненадёжные данные, становятся мишенью для атак;
слабая проверка входных данных превращает инструменты в векторы атак;
атаки с инъекцией подсказок могут использовать любые каналы ввода (комментарии, формы, URL);
автономные агенты выполняют вредоносные инструкции, воспринимая их как обычные задачи разработки.
Что делать пользователям и разработчикам:
строго проверять входные данные во всех ИИ‑инструментах;
разделять системные инструкции и пользовательские данные;
регулярно обновлять ПО и IDE;
обучать сотрудников основам кибербезопасности;
внедрять многоуровневую проверку изменений в коде.