Исследователи AISLE нашли критическую уязвимость в ИИ-редакторах кода Cursor, Microsoft Visual Studio Code и Google Antigravity. Ошибка могла привести к удалённому выполнению кода, если разработчик открывал специально подготовленную ссылку из сообщения Git-коммита.

Проблему уже закрыли вендоры, но сам инцидент показал куда более широкий риск: популярные AI-IDE всё чаще строят на общей кодовой базе и наследуют не только удобные функции, но и ошибки безопасности.

Что произошло

RCE-уязвимость позволяет злоумышленнику запустить команды на чужом устройстве. В этом случае атакующему не нужен доступ к паролю или аккаунту: достаточно, чтобы жертва кликнула по вредоносной ссылке в привычном рабочем контексте.

Для разработчика это особенно опасно. Среда разработки часто хранит токены, SSH-ключи, доступы к репозиториям и другие секреты, которые открывают путь дальше — в корпоративную инфраструктуру.

Как технически работала атака

Сценарий выглядел почти буднично. Злоумышленник вставлял вредоносную ссылку в сообщение коммита, а разработчик открывал её прямо из интерфейса IDE при просмотре истории изменений.

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

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

Почему пострадало сразу несколько редакторов

Cursor вырос из Visual Studio Code и унаследовал его архитектуру. Позже похожую проблему нашли и в Google Antigravity, который тоже опирается на решения из экосистемы VS Code.

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

Почему это опасно для компаний

Рабочее место разработчика давно стало одной из самых ценных точек входа в компанию. Через него можно добраться до репозиториев, облачных ключей, секретов CI/CD и внутренних сервисов.

Если злоумышленник получает контроль над IDE, он часто выигрывает время и доступ сразу к нескольким системам. В такой ситуации уже не спасает привычная логика «это всего лишь редактор».

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

Как понять, касается ли это вас

Если вы пользуетесь Cursor, Visual Studio Code или Google Antigravity, риск актуален уже по факту установки этих редакторов до обновления с исправлением. Особенно внимательно стоит отнестись к рабочим станциям, где хранятся ключи доступа, токены и другие секреты.

Тревожные признаки просты: странная активность в проектах, неизвестные процессы, внезапные изменения файлов, неожиданные сетевые запросы, пропажа токенов или странные команды в истории терминала.

Как защититься

Первое — обновить редакторы до последних версий. Второе — проверить рабочие станции разработчиков на следы подозрительной активности.

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

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

Практический чек-лист

  • Обновить Cursor, Visual Studio Code или Google Antigravity до последней версии.
  • Проверить рабочую станцию на неизвестные процессы, расширения и подозрительные сетевые соединения.
  • Заменить токены, API-ключи и SSH-ключи, если они могли храниться локально.
  • Просмотреть историю коммитов и ссылки, которые открывались из интерфейса редактора.
  • Ограничить доступ IDE к секретам, которые не нужны для повседневной работы.
  • Настроить отдельный контроль за кодом и подсказками, которые генерируют ИИ-инструменты.
  • Напомнить команде: даже привычный элемент рабочего процесса может стать точкой атаки.
Поделиться: