Две критические уязвимости Cursor с оценкой 9,8 из 10 позволяли обычной на вид подсказке отключить встроенную песочницу и запускать любые команды на компьютере разработчика. Для атаки не требовались ни клик по ссылке, ни подтверждение опасного действия, а значит для команд, которые уже завязывают разработку на AI-редактор, это не теоретическая неприятность, а прямой риск для рабочих машин, репозиториев и облачных доступов.
Об этом сообщает The Hacker News со ссылкой на исследование Cato AI Labs. Исследователи назвали связку DuneSlide, а сами баги получили идентификаторы CVE-2026-50548 и CVE-2026-50549. По данным публикации, исправление уже выпущено: патч вошел в Cursor 3.0, релиз которого состоялся 2 апреля 2026 года, а уязвимыми считаются все версии до 3.0. На фоне заявления разработчика Cursor о том, что инструмент используют более половины компаний из списка Fortune 500, история выглядит особенно показательно: речь идет не о нишевой IDE для энтузиастов, а о продукте, который уже встроен в корпоративную разработку.
Суть проблемы в том, что песочница Cursor, появившаяся в ветке 2.x, должна была изолировать команды, которые AI-агент отправляет в терминал. Идея здравая: если модель сгенерировала лишнее или наткнулась на вредоносную инструкцию, команда выполняется в ограниченной среде и не получает полный доступ к системе. DuneSlide показывает, что защита ломается не за счет сложного эксплойта, а через саму логику удобства. Атакующий прячет инструкции в контенте, который агент читает за пользователя, например в ответе веб-поиска или в подключенном сервисе через Model Context Protocol. Пользователь задает нормальный вопрос, скрытая команда едет вместе с контекстом, и дальше агент сам доводит атаку до конца. Для русскоязычных команд это важный сигнал: если AI-инструмент ходит в интернет, подключает внешние контексты и умеет выполнять команды, граница между «подсказкой» и «удаленным кодом» становится неприятно тонкой.
Первая уязвимость Cursor, CVE-2026-50548, завязана на параметр working_directory у инструмента run_terminal_cmd. Песочница разрешала запись в рабочую директорию команды, и если агент указывал нестандартный путь, Cursor без дополнительных проверок добавлял его в список допустимых для записи мест. Это позволяло направить запись не в папку проекта, а, например, в системный файл. В публикации приводится конкретная цель на macOS: вспомогательный файл песочницы cursorsandbox внутри пакета приложения Cursor. Если его переписать, следующие команды запускаются уже без изоляции. В качестве другой мишени упоминаются shell-инициализационные файлы вроде ~/.zshrc. Иначе говоря, защитный контур можно было не «взламывать» в классическом смысле, а просто убедить его самим отключить себя.
Вторая проблема, CVE-2026-50549, использовала слабое место в проверке симлинков. Перед записью Cursor пытался разрешить символическую ссылку и убедиться, что реальный путь остается внутри проекта. Ошибка была в запасном сценарии: если проверка не срабатывала, например потому что целевой файл еще не существовал или злоумышленник убирал права на чтение у одной из директорий по пути, редактор прекращал реальную проверку и доверял «безопасному» пути внутри проекта. Дальше оставалось создать симлинк наружу и снова записать данные в тот же вспомогательный файл песочницы. Конечный эффект у обеих дыр одинаковый: следующая команда выполняется уже с правами пользователя. А вместе с правами пользователя обычно идут токены, SSH-ключи, доступы к Git, облачным IDE, SaaS-сервисам и внутренним панелям. Для компаний это означает, что компрометация может начаться с одного безобидного запроса к агенту, а закончиться уже далеко за пределами локального проекта.
Отдельно интересно, как развивалась история с исправлением. Cato AI Labs сообщила о двух багах 19 февраля 2026 года. По версии исследователей, через четыре дня Cursor отклонил отчет, сославшись на то, что злоупотребление MCP-серверами, даже стандартными, вроде официального Linear workspace, не входит в его модель угроз. После эскалации 26 февраля отчеты reopened, уязвимости прошли триаж, а фиксы вошли в Cursor 3.0. CVE были присвоены 5 июня. Это хороший пример типичной проблемы эпохи AI-агентов: вендоры еще спорят, считать ли внешний контент «недоверенным по умолчанию», а атакующие уже считают. Если инструмент сам читает веб-страницы, таскает контекст из интеграций и умеет что-то запускать на машине, модель угроз приходится строить не от лучшего сценария, а от худшего.
Контекст для Cursor тоже не самый комфортный. The Hacker News напоминает, что это не первый случай, когда prompt injection в AI-редакторе заканчивается выполнением команд. В августе 2025 года та же исследовательская команда, тогда под именем Aim Security, описала CurXecute: вредоносное сообщение в Slack переписывает конфигурацию ~/.cursor/mcp.json и запускает команды даже после отказа пользователя подтвердить изменение. Позже Check Point Research раскрыла MCPoison, где злоумышленник мог один раз добиться одобрения MCP-конфига, а затем незаметно подменить команды без повторного запроса. В феврале 2026-го всплыла еще одна история: ловушка в Git hook срабатывала, как только агент запускал Git-команду. Песочница в ветке 2.x была ответом Cursor на эту серию проблем. DuneSlide, по сути, показал, что сам ответ тоже нужно защищать.
Для разработчиков и руководителей здесь вывод довольно приземленный. AI-редактор уже нельзя оценивать только по качеству автодополнения и скорости генерации кода. Если агент умеет дергать терминал, читать внешние источники и подключаться к MCP-сервисам, он становится частью атакуемой поверхности рабочего места. Практический минимум после этой истории выглядит так: обновиться до Cursor 3.0 или новее, проверить, где в команде разрешены внешние MCP-подключения и веб-поиск, а также перестать считать локальную песочницу достаточной гарантией безопасности. На глаз эта проблема не исчезнет: чем активнее coding agents получают право действовать от имени разработчика, тем чаще отрасли придется решать не вопрос удобства, а вопрос недоверия к любому входящему контексту.