Взлом Amazon Q, три CVE в Cursor, захват через GitHub: хроника атак на AI-инструменты

2025 год стал переломным: AI-ассистенты перестали быть теоретической угрозой и превратились в реальный вектор атак. Три громких инцидента за один год показали, что индустрия не готова к тому, что сама создала.

Год, когда AI-агенты стали мишенью

До 2025 года атаки на AI-инструменты существовали в области академических исследований и демонстрационных proof-of-concept. Специалисты предупреждали: любой AI-ассистент, который читает произвольные данные и выполняет действия, уязвим к prompt injection. Но индустрия двигалась слишком быстро, чтобы слушать. Расширения устанавливались сотнями тысяч, MCP-серверы подключались одной командой, а AI-агентам давался доступ к файловой системе, терминалу и облачным ресурсам.

В 2025 году теория столкнулась с практикой. Три инцидента, каждый со своим вектором, обнажили системную проблему: AI-агенты доверяют всему, что читают. И этим можно воспользоваться.

Amazon Q Developer: одна строка, которая чуть не уничтожила инфраструктуру

В декабре 2025 года исследователи из Lakera обнаружили критическую уязвимость в расширении Amazon Q Developer для VS Code. Это расширение, установленное 964 000 раз, предоставляло AI-ассистенту от AWS полный доступ к рабочему пространству разработчика, включая терминал и AWS-ресурсы.

Механизм атаки был элегантно простым. Через скомпрометированный GitHub-токен злоумышленник мог внедрить в файл репозитория специально сформированную строку, невидимую при обычном чтении кода, но распознаваемую языковой моделью как инструкцию. Когда разработчик просил Amazon Q проанализировать код или сгенерировать решение, модель читала этот файл и воспринимала внедрённый текст как легитимную команду.

Внедрённая инструкция содержала цепочку деструктивных команд: удаление файловой системы (rm -rf /) и уничтожение AWS-ресурсов через CLI — S3-бакетов, EC2-инстансов, IAM-ролей. По иронии, только синтаксическая ошибка в теле вредоносной команды предотвратила реальный ущерб. Если бы атакующий проверил свой payload более тщательно, последствия были бы катастрофическими.

Масштаб потенциального урона

Amazon Q работает с учётными данными AWS, которые разработчик уже настроил в своём окружении. AI-агент выполняет команды с теми же привилегиями, что и пользователь. А разработчик, как правило, имеет доступ к продакшн-ресурсам — базам данных, хранилищам, вычислительным кластерам.

964 000 установок — это почти миллион разработчиков, работавших с инструментом, который можно было превратить в оружие через один pull request. Один вредоносный коммит в популярную open-source-библиотеку мог запустить цепную реакцию: каждый разработчик, открывший репозиторий с Amazon Q, рисковал потерей инфраструктуры.

Cursor IDE: три уязвимости, один паттерн

Cursor — один из самых быстрорастущих AI-редакторов кода — за 2025 год получил сразу три CVE. Каждая уязвимость эксплуатировала фундаментальную проблему: AI-агент не различает данные и инструкции.

CurXecute (CVE-2025-54135, CVSS 8.6)

Самая критичная из трёх уязвимостей. Одна строка в конфигурации MCP-сервера давала атакующему полный удалённый контроль над машиной жертвы — Remote Code Execution. MCP (Model Context Protocol) — открытый протокол для подключения внешних инструментов к AI-ассистентам — к этому моменту стал стандартом де-факто. Cursor поддерживал подключение MCP-серверов через JSON-конфигурацию в корне проекта.

Атакующий создавал вредоносный MCP-сервер и распространял конфигурацию через популярные шаблоны проектов, boilerplate-репозитории или pull request в open-source-проекты. Разработчик клонировал репозиторий, Cursor автоматически подхватывал конфигурацию, и с этого момента каждое обращение к AI-ассистенту могло привести к выполнению произвольного кода — без дополнительных подтверждений, без предупреждений.

MCPoison (CVE-2025-54136)

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

Это классическая атака типа TOCTOU (Time of Check, Time of Use): проверка безопасности происходит в один момент, а использование ресурса — в другой, когда условия уже изменились. Пользователь одобрял один сервер, а работал с совершенно другим.

Обход защиты файлов (CVE-2025-59944)

Третья уязвимость целилась в механизм .cursorignore — возможность пометить определённые файлы как защищённые. Предполагалось, что AI-агент не будет их читать или изменять. Однако через специально сформированный промпт можно было обойти эту защиту и заставить агента модифицировать любой файл проекта, включая .env, конфигурации CI/CD и файлы деплоя.

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

GitHub MCP: когда Issues становятся оружием

Третий вектор атак оказался самым коварным — он использовал повседневный рабочий инструмент каждого разработчика. Исследователи из Invariant Labs обнаружили, что AI-агенты, подключённые к GitHub через MCP-сервер, могут быть захвачены через обычные Issues и комментарии к pull request.

Атака работала обманчиво просто. Злоумышленник создавал issue в публичном репозитории, содержащий скрытую prompt injection — текст, который выглядит как обычный комментарий для человека, но содержит инструкцию для AI-модели. Когда разработчик просил AI-ассистента проанализировать issue, отсортировать backlog или подготовить ответ, агент читал вредоносный текст и воспринимал его как команду.

Результаты были пугающими: через одну issue агент мог прочитать содержимое приватных репозиториев организации, эксфильтровать секреты и токены, создать pull request с вредоносным кодом и даже одобрить его. Фактически, одна строка текста в публичном issue могла скомпрометировать всю GitHub-организацию.

Почему это особенно опасно

В отличие от первых двух атак, здесь не нужен доступ к репозиторию жертвы. Достаточно создать issue в любом публичном проекте, который команда использует или мониторит. Злоумышленнику не нужно знать ничего о внутренней инфраструктуре — только то, что разработчики используют AI-агента с доступом к GitHub.

Общий паттерн: архитектурное слепое доверие

Все три инцидента объединяет один фундаментальный паттерн: AI-агент получает данные из недоверенного источника и обрабатывает их наравне с легитимными инструкциями пользователя. Это не ошибка конкретного разработчика или конкретного продукта — это архитектурная проблема всего класса AI-инструментов.

Prompt injection работает потому, что языковые модели не имеют надёжного механизма разделения данных и инструкций. Когда модель читает файл, issue или конфигурацию, она не может гарантированно отличить «это контент для анализа» от «это команда для выполнения». Любой текст потенциально является управляющей инструкцией.

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

Sandbox: не рекомендация, а требование

Главный вывод 2025 года формулируется однозначно: AI-агент должен работать в изолированном окружении. Контейнерная изоляция, минимальные привилегии, отсутствие прямого доступа к продакшн-ресурсам — это не продвинутые практики для параноиков, а базовые гигиенические требования.

Подтверждение каждого действия пользователем — мера необходимая, но недостаточная. Исследования UX показывают, что разработчики быстро вырабатывают «усталость от подтверждений» (alert fatigue) и начинают одобрять действия не глядя. Нужен многоуровневый подход: изоляция среды выполнения, ограничение сетевого доступа, логирование всех операций, автоматический анализ выходных данных агента.

Что делать прямо сейчас

Инциденты 2025 года формируют чёткий набор практик для любой команды, использующей AI-инструменты разработки:

• Zero Trust к AI-агенту. Агент — не доверенный коллега, а потенциально скомпрометированный исполнитель. Каждое его действие проходит через контроль доступа.
• Контейнерная изоляция. AI-агент работает в контейнере без доступа к хостовой системе, продакшн-сети и реальным учётным данным.
• Принцип минимальных привилегий. Агент получает доступ только к файлам и ресурсам, необходимым для текущей задачи. Не больше.
• Аудит MCP-серверов. Каждый подключённый MCP-сервер — потенциальный вектор атаки. Конфигурации проверяются при каждом изменении.
• Полное логирование. Все действия AI-агента записываются и анализируются. Аномальное поведение блокируется автоматически.
• Обучение команды. Каждый разработчик должен понимать, что prompt injection — реальный вектор атаки, а не академическая абстракция.