Check Point обнаружила критическую уязвимость IDE курсора: скрытая угроза в разработке с использованием ИИ

С учетом того, что глобальный рынок инструментов кодирования с использованием ИИ оценивается примерно в 6.7 млрд долларов США в 2024 году и, по прогнозам, превысит 25.7 млрд долларов США к 2030 годуДоверие к инструментам, лежащим в основе современной разработки программного обеспечения, никогда не было столь важным. В основе этого бума лежит новый класс генераторов кода на базе ИИ, таких как Cursor, которые сочетают традиционные среды программирования с искусственным интеллектом для автоматизации и ускорения процессов кодирования.

В частности, Cursor быстро завоевал популярность среди разработчиков благодаря глубокой интеграции с большими языковыми моделями (LLM), что позволяет пользователям генерировать, отлаживать и рефакторить код с помощью подсказок на естественном языке. Он работает как инструмент на базе искусственного интеллекта. интегрированная среда разработки (IDE)— программное приложение, объединяющее в одном месте основные инструменты, необходимые разработчикам для написания, тестирования и управления кодом.

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

Этот риск стал очень реальным с недавним открытием CVE-2025-54136, критическая уязвимость безопасности, обнаруженная Check Point ResearchЭта уязвимость не связана с ошибкой в пользовательском коде — проблема в том, как Cursor обрабатывает доверие и автоматизацию. Она позволяет злоумышленникам незаметно выполнять вредоносные команды на компьютере жертвы, используя доверенную функцию автоматизации, которая изначально не предназначалась для использования в качестве оружия.

То, что на первый взгляд кажется удобным Помощник по кодированию с использованием искусственного интеллектав данном случае стал бэкдором, который мог сработать без предупреждения каждый раз, когда разработчик открывал свой проект.

Ошибка: эксплуатация доверия посредством MCP

В центре этой уязвимости находится Курсор. Протокол контекста модели (MCP)— фреймворк, позволяющий разработчикам определять автоматизированные рабочие процессы, интегрировать внешние API и выполнять команды в среде IDE. MCP функционируют как плагины и играют центральную роль в оптимизации использования ИИ для генерации кода, отладки и настройки проекта.

Проблема безопасности связана с тем, как Cursor обрабатывает доверие. При введении конфигурации MCP пользователю предлагается один раз подтвердить её. Однако после этого первоначального подтверждения Cursor никогда не проверяет конфигурацию повторно, даже если её содержимое изменяется. Это создаёт опасную ситуацию: кажущийся безобидным MCP может быть незаметно заменён вредоносным кодом, и изменённая конфигурация будет выполнена без появления новых запросов или предупреждений.

Злоумышленник может:

1. Поместите безобидный на вид MCP-файл в общий репозиторий.

2. Подождите, пока член команды одобрит его в Курсоре.

3. Измените MCP, включив в него вредоносные команды (например, обратные оболочки или скрипты извлечения данных).

4. Получайте автоматический, бесшумный доступ каждый раз при повторном открытии проекта в Cursor.

Ошибка заключается в том, что Курсор привязывает доверие к Имя ключа MCP, а не к содержимому конфигурации. После того, как имя стало доверенным, оно может остаться неизменным, в то время как лежащее в его основе поведение становится опасным.

Реальное влияние: скрытность и настойчивость

Эта уязвимость представляет собой не просто теоретический риск — она представляет собой практический вектор атаки в современных средах разработки, где проекты распределяются между группами посредством систем контроля версий, таких как Git.

• Постоянный удаленный доступ: Как только злоумышленник изменяет MCP, его код автоматически запускается каждый раз, когда участник проекта открывает его.

• Тихая казнь: Никаких подсказок, предупреждений или оповещений не отображается, что делает эксплойт идеальным для долгосрочного использования.

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

• Кража кодовой базы и IP-адресов: Поскольку атака происходит в фоновом режиме, она становится тихим проходом к внутренним активам и интеллектуальной собственности.

• Слабость цепочки поставок: Это подчеркивает хрупкость доверия к процессам разработки на базе ИИ, которые часто полагаются на автоматизацию и общие конфигурации без надлежащих механизмов проверки.

Машинное обучение встречает «слепые зоны» безопасности

Уязвимость Cursor демонстрирует более масштабную проблему, возникающую на стыке машинного обучения и инструментов разработки: чрезмерное доверие к автоматизации. По мере того, как всё больше платформ для разработчиков интегрируют функции на основе ИИ — от автодополнения до интеллектуальной конфигурации — потенциальная поверхность атак значительно расширяется.

Такие термины, как удаленное выполнение кода (RCE) и обратная оболочка больше не предназначены для хакерских инструментов старой школы. В данном случае RCE достигается за счёт использования проверенных средств автоматизации. Обратный шелл, при котором машина жертвы подключается к злоумышленнику, можно инициировать, просто изменив уже доверенную конфигурацию.

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

Что делает этот вектор атаки таким опасным

Что делает уязвимость CVE‑2025‑54136 особенно опасной, так это сочетание скрытности, автоматизации и устойчивости. В типичных моделях угроз разработчики обучены выявлять вредоносные зависимости, странные скрипты и внешние эксплойты. Но здесь риск скрыт в самом рабочем процессе. Это случай, когда злоумышленник эксплуатирует доверять а не качество кода.

• Невидимый вход в атмосферу: Атака запускается каждый раз при открытии IDE, без каких-либо визуальных подсказок или журналов, если только не осуществляется внешний мониторинг.

• Низкий барьер для входа: Любой участник, имеющий право записи в репозиторий, может превратить MCP в оружие.

• Масштабируемость эксплойта: В организациях, где много разработчиков используют общие инструменты, один измененный MCP может широко распространить компрометацию.

Рекомендуемые меры

Check Point Research Компания Cursor ответственно раскрыла информацию об уязвимости 16 июля 2025 года. 30 июля 2025 года компания выпустила исправление, устраняющее проблему, однако более широкие последствия остаются.

Чтобы защититься от подобных угроз, организациям и разработчикам следует:

1. Относитесь к MCP как к коду: Проверяйте и контролируйте версии всех конфигураций автоматизации. Относитесь к ним как к части кодовой базы, а не как к безобидным метаданным.

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

3. Ограничить доступ на запись: Используйте средства управления доступом к репозиторию, чтобы ограничить круг лиц, которые могут изменять файлы автоматизации.

4. Аудит рабочих процессов ИИ: Понимайте и документируйте, что делает каждая конфигурация с поддержкой ИИ, особенно в командной среде.

5. Мониторинг активности IDE: Отслеживайте и оповещайте об автоматизированном выполнении команд, инициированном IDE, для выявления подозрительного поведения.

Вывод: автоматизация без контроля — это уязвимость

Эксплойт в Cursor IDE должен послужить предостережением для всей индустрии программного обеспечения. Инструменты на базе ИИ больше не являются чем-то факультативным — они становятся неотъемлемой частью. Но с их внедрением должно произойти изменение нашего отношения к доверию, валидации и автоматизации.

Уязвимость CVE‑2025‑54136 раскрывает риски, связанные с удобными средами разработки, которые не проверяют текущее поведение. Чтобы обеспечить безопасность в эту новую эпоху, разработчикам и организациям необходимо переосмыслить истинное значение понятия «доверенный» и гарантировать, что автоматизация не станет скрытой уязвимостью, скрывающейся на виду. Читатели, желающие получить техническое представление об уязвимости, могут ознакомиться с отчётом Check Point Research.