В редакторе кода с искусственным интеллектом Cursor обнаружены две критические уязвимости, которые позволяют обычному текстовому запросу выйти из защитной песочницы приложения и выполнить произвольные команды на компьютере разработчика. Для эксплуатации не требуется никаких действий со стороны пользователя: не нужно нажимать кнопки подтверждения или соглашаться на выполнение операций.
Уязвимости были обнаружены исследователями Cato AI Labs и получили название DuneSlide. Им присвоены идентификаторы CVE-2026-50548 и CVE-2026-50549. Обе получили оценку 9,8 балла по шкале CVSS 3.x (или 9,3 балла по новой версии CVSS 4.0).
Исправления уже доступны. Обе проблемы устранены в Cursor 3.0, выпущенном 2 апреля. Все версии редактора до 3.0 остаются уязвимыми. По данным разработчиков Cursor, инструмент используют более половины компаний из списка Fortune 500, поэтому пользователям рекомендуется как можно скорее обновить приложение.
Как работает песочница и каким образом удалось ее обойти
Начиная с ветки 2.x агент Cursor по умолчанию выполняет терминальные команды внутри песочницы. Такой механизм ограничивает доступ процессов к файловой системе и другим ресурсам, чтобы ошибочная или вредоносная команда не могла нанести ущерб компьютеру пользователя.
Атака DuneSlide позволяет выйти за пределы этой песочницы. Эксплуатация начинается с prompt injection. Злоумышленнику не требуется получать доступ к самому Cursor. Вместо этого вредоносные инструкции внедряются в источник данных, который агент читает от имени пользователя. Это может быть сервис, подключенный через Model Context Protocol (MCP), либо веб-страница, полученная в результате поиска.
Пользователь задает обычный запрос, а скрытые инструкции незаметно передаются вместе с ответом. Поскольку подтверждение действий не требуется, атака относится к категории zero-click.
Обе уязвимости используют одинаковую схему: заставить агента записать файл, который он не должен изменять, после чего отключить механизм песочницы.
CVE-2026-50548
Первая уязвимость связана с параметром working_directory.
Песочница разрешает запись файлов в рабочую директорию команды. Эта директория задается необязательным параметром working_directory инструмента run_terminal_cmd.
Если агент указывает путь, отличный от стандартного, Cursor автоматически добавляет его в список директорий, доступных для записи, без дополнительной проверки.
Вредоносные инструкции могут указать путь не к каталогу проекта, а к системному файлу. Например, можно перезаписать вспомогательный компонент песочницы:
/Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandboxПосле его замены последующие команды будут выполняться уже без каких-либо ограничений песочницы.
В качестве целей также могут использоваться файлы автозагрузки оболочки, например:
~/.zshrcCVE-2026-50549
Вторая уязвимость связана с проверкой символических ссылок.
Перед записью файла Cursor разрешает символические ссылки (symlink), чтобы убедиться, что фактический путь находится внутри каталога проекта.
Проблема возникает в случае ошибки проверки. Если целевой файл отсутствует или злоумышленник временно блокирует доступ к одному из каталогов в цепочке пути, Cursor прекращает проверку и начинает доверять исходному пути внутри проекта.
Злоумышленник может создать символическую ссылку, ведущую за пределы проекта, специально вызвать сбой проверки и добиться записи в тот же вспомогательный файл песочницы.
В результате достигается тот же эффект — отключение песочницы другим способом.
После отключения защиты следующая команда уже выполняется с правами пользователя. Это дает возможность получить полный контроль над компьютером разработчика, а также доступ к облачным сервисам и SaaS-платформам, в которых авторизован Cursor.
Для компрометации системы достаточно одного внешне безобидного запроса.
На момент публикации исследователи не обнаружили признаков эксплуатации этих уязвимостей в реальных атаках. В Cato подчеркивают, что работа носит исследовательский характер, а в публичных базах данных отсутствуют сведения об известных случаях использования этих ошибок.
Хронология исправления
Cato сообщила об обеих уязвимостях 19 февраля.
По данным исследователей, спустя четыре дня разработчики Cursor отклонили отчеты, заявив, что подобные сценарии не входят в модель угроз продукта, включая использование стандартных MCP-серверов, таких как официальный рабочий пространство Linear.
26 февраля Cato повторно направила информацию. После этого Cursor возобновила рассмотрение отчетов, провела анализ и включила исправления в релиз версии 3.0.
Идентификаторы CVE были присвоены 5 июня.
Cursor также опубликовала собственное уведомление безопасности для уязвимости, связанной с символическими ссылками, а соответствующая запись появилась в базе NVD.
Не первая подобная проблема
DuneSlide стала очередной уязвимостью Cursor, в которой вредоносные инструкции через prompt injection приводят к выполнению произвольного кода, обходя различные защитные механизмы.
Ранее были раскрыты следующие проблемы:
CurXecute (CVE-2025-54135, август 2025 года), обнаруженная той же командой исследователей, когда она работала под названием Aim Security. Вредоносное сообщение в Slack изменяло конфигурационный файл
~/.cursor/mcp.jsonи запускало команды даже после того, как пользователь отклонял изменение. Уязвимость была исправлена в версии 1.3.MCPoison (CVE-2025-54136), обнаруженная Check Point Research. Она позволяла один раз получить одобрение конфигурации MCP, после чего незаметно заменить команды на вредоносные без повторного подтверждения.
CVE-2026-26268 (февраль 2026 года), позволявшая скрыть вредоносный Git hook в репозитории, который автоматически выполнялся при запуске агентом любой Git-команды. Исправление вошло в версию 2.5.
Песочница, появившаяся в ветке Cursor 2.x, стала ответом разработчиков на предыдущую волну подобных атак. DuneSlide показала, что этот механизм также можно обойти.
В Cato сообщили, что уже подготовили материалы о похожих уязвимостях в других ИИ-агентах для программирования. По мнению исследователей, проблема носит системный характер и не ограничивается отдельными ошибками реализации.
Это оставляет открытым вопрос о том, должны ли ИИ-агенты, работающие с открытым интернетом, по умолчанию считать любой входящий контент потенциально недоверенным, либо защита и дальше будет строиться на последовательном устранении отдельных уязвимостей.
Источник: HN