Исследователи показали, как «обычный» репозиторий может заставить ИИ‑ассистента записать данные не туда, куда кажется в окне подтверждения. Риск особенно неприятен тем, что выглядит как рутинная настройка проекта — пока не выясняется, что изменились SSH‑ключи или автозапуск команд в терминале.
Команды всё чаще доверяют ИИ‑ассистентам рутинные действия: открыть проект, «поднять» окружение, поправить конфиг, прогнать тесты. Но свежая находка исследователей напоминает: если инструменту разрешено читать и писать файлы на машине разработчика, то безопасность упирается не только в модель, но и в то, как устроены файловые операции и окна подтверждения действий.
Что обнаружили
Исследователи Wiz описали приём, который назвали GhostApproval. Он использует давнюю особенность файловых систем Unix-подобных ОС — символические ссылки (symlink). Суть в том, что файл внутри проекта может оказаться «указателем» на другой путь в системе. Если программа не проверяет, куда именно ведёт ссылка, запись в «безобидный» файл может фактически изменить чувствительный системный файл.
Проблема усиливается тем, что в ряде инструментов окно подтверждения правки показывает разработчику имя исходного файла, а не реальный путь назначения. В итоге пользователь нажимает «Accept», будучи уверенным, что разрешает правку локального конфига проекта, но ассистент вносит изменения уже за пределами репозитория.
Как выглядит атака на практике
Демонстрационный сценарий строится вокруг репозитория с «подготовленным» файлом‑ссылкой. Например, в проект кладут symlink с названием вроде project_settings.json, который на самом деле указывает на ~/.ssh/authorized_keys. Дальше в README остаётся правдоподобная просьба: «добавь одну строку в настройки». ИИ‑агент выполняет задачу и записывает «строку» — но попадает она уже в SSH‑ключи, что потенциально открывает атакующему вход на машину (если SSH доступен извне).
Есть и вариант без SSH: запись идёт в ~/.zshrc или другой файл автозапуска оболочки. Тогда вредоносная команда выполнится при следующем открытии терминала.
Важно: в публикации подчёркивается, что это исследовательская демонстрация, и признаков массового использования техники в реальных атаках не приводится.
Какие инструменты оказались уязвимыми
По данным проверки Wiz, техника срабатывала против шести популярных помощников для разработки:
- Amazon Q Developer
- Anthropic Claude Code
- Augment
- Cursor
- Google Antigravity
- Windsurf
Статус исправлений — и почему он отличается
На момент публикации часть вендоров уже выпустила обновления, часть подтвердила получение отчёта, но без публичного фикса, а по одному инструменту есть спор по классификации риска.
- Amazon Q Developer: исправление в Language Server
1.69.0(указан CVE-2026-12958). - Cursor: исправление в версии
v3.0(указан CVE-2026-50549). - Google Antigravity: сообщается, что исправление выпущено (CVE в процессе).
- Augment и Windsurf: подтверждено получение отчёта, но исправления на момент публикации ещё не заявлены.
- Claude Code: позиция Anthropic описана как спорная — компания указывает, что сценарий находится вне её модели угроз, при этом в текущих версиях есть предупреждения про symlink.
Почему это важно именно для обычной разработки, а не только для безопасности
Проблема бьёт по самому привычному рабочему сценарию: разработчик берёт новый репозиторий (или обновление чужого), просит ассистента «настроить проект», и дальше идёт по подсказкам README. В классическом мире это тоже риск, но ИИ‑агенты ускоряют и «упрощают» выполнение инструкций — а значит, повышают вероятность пропустить момент, где нужно остановиться и проверить, что именно будет изменено.
Ещё один неприятный момент — иллюзия контроля. Окно «Разрешить/Запретить» воспринимается как страховка. Но если оно показывает не тот реальный путь, то превращается в формальность.
Что можно сделать прямо сейчас: короткий чек‑лист
- Обновите ассистент и расширения IDE до актуальных версий — многие исправления распространяются именно через плагины и language server.
- Не запускайте “setup” на незнакомых репозиториях вслепую. Быстрый просмотр README и подозрительных «настроечных» файлов экономит часы разборов инцидента.
- Ограничьте доступ агента к файловой системе: по возможности работайте в контейнере/песочнице или выдавайте доступ только к папке проекта, без домашнего каталога.
- Проверяйте следы изменений вне проекта после работы с новым репозиторием. Практический пример: посмотреть timestamps чувствительных файлов вроде
~/.zshrcи~/.ssh/authorized_keys. - Командный уровень: договоритесь о правилах “AI‑onboarding” для новых репозиториев (что ассистенту можно делать автоматически, а что — только после ручной проверки).
Для разработчиков это история не про «не пользоваться ИИ», а про то, что агентам нужно выдавать права как любому инструменту автоматизации: минимально достаточные, с понятным периметром и проверяемыми действиями.
Источник: The Hacker News
