Уязвимость Amazon Q с идентификатором CVE-2026-12957 и оценкой CVSS 8.5 позволяла превратить обычный git clone в запуск произвольных команд на машине разработчика с последующей кражей облачных учетных данных. Для этого было достаточно открыть репозиторий, подтвердить доверие к рабочей области, а дальше AI-ассистент сам поднимал вредоносный MCP-сервер. Для российской IT-аудитории это еще одно напоминание: удобство AI-инструментов в IDE все чаще упирается не в качество подсказок, а в базовую модель доверия к коду и конфигам.
О проблеме, как пишет The Hacker News, сообщила Wiz Research, которая нашла баг в механике обработки Model Context Protocol в Amazon Q Developer. Речь идет о файле .amazonq/mcp.json внутри открытого workspace. Amazon Q читал эту конфигурацию и запускал указанные в ней MCP-серверы, то есть локальные процессы, через которые AI-помощник получает доступ к базам данных, API, сборочным инструментам и другим внешним ресурсам. На практике это означало простую вещь: если такой процесс стартует, он уже исполняет команды на машине разработчика и наследует ее окружение.
А окружение у разработчика обычно довольно щедрое. Там лежат AWS-ключи, токены CLI, секреты API, SSH-agent sockets и прочие вещи, которые не должны гулять по сети без приглашения. В proof of concept исследователи заставили конфиг выполнить aws sts get-caller-identity и отправить результат на сервер атакующего, то есть фактически утащить активную AWS-сессию. Дальше сценарий зависит уже не от фантазии злоумышленника, а от прав конкретного инженера: можно закрепиться через IAM, дотянуться до внутренних сервисов или аккуратно двинуться в сторону production. Без пароля, без повторного входа, без отдельного окна с красной надписью «вы уверены?». Достаточно того, что пользователь уже доверился проекту.
Где именно сломалась логика доверия
Ключевой спор здесь не о наличии user interaction, а о том, что именно пользователь санкционировал. Amazon в advisory указывает, что человек должен был доверить workspace среде разработки, и потому в оценке CVSS взаимодействие пользователя считается необходимым. Wiz описывает проблему жестче: до патча не было отдельного согласия именно на запуск MCP-серверов из конфигурации репозитория. То есть разработчик говорил IDE «этому проекту можно открыться», а получал в комплекте молчаливый запуск процессов с доступом к его рабочей облачной сессии. Для supply chain-атак это почти идеальная конструкция: вредоносный код лежит не в бинарнике, не в зависимостях и даже не в post-install, а в проектной конфигурации инструмента, которому пользователь сам привык доверять.
Amazon проблему уже закрыла. Исправление для CVE-2026-12957 вошло в Language Servers for AWS 1.65.0, однако в бюллетене компания рекомендует обновляться сразу до 1.69.0. Эта версия закрывает и вторую уязвимость, CVE-2026-12958, связанную с отсутствующей проверкой симлинков, что могло приводить к произвольной записи файлов за пределами доверенной рабочей области. Минимальные безопасные версии плагинов такие: для VS Code — 2.20 и новее, для JetBrains — 4.3 и новее, для Eclipse — 2.7.4 и новее, для Visual Studio Toolkit — 1.94.0.0 и новее. Ядро Language Servers for AWS обновляется автоматически, если сеть не мешает, а перезапуск IDE подтягивает свежую сборку. В корпоративной среде именно эта оговорка про сеть обычно и оказывается самой неприятной: автообновление хорошо работает ровно до первого прокси, зеркала пакетов и жесткой политики выхода в интернет.
Публичных свидетельств эксплуатации уязвимости пока нет. В записи CISA ADP для CVE-2026-12957 указано none, то есть подтвержденных случаев злоупотребления на момент публикации не было. Таймлайн раскрытия тоже выглядит аккуратно: Wiz сообщила о находке 20 апреля 2026 года, исправление появилось 12 мая, а публичный разбор вышел 26 июня. Это не история про баг, который годами лежал на виду и никому не был нужен; скорее, это очередной пример того, насколько быстро растет класс уязвимостей на стыке AI-ассистентов, локальной разработки и доверия к содержимому репозитория.
Почему это уже не единичный инцидент
Самый неприятный вывод не в том, что у Amazon Q была дыра, а в том, что она рифмуется с похожими инцидентами у других AI-инструментов для разработчиков. В материале упоминаются Claude Code с CVE-2025-59536, Cursor с CVE-2025-54136 и Windsurf с CVE-2026-30615. Детали у них различаются, но общий паттерн один и тот же: проектная конфигурация или контролируемое атакующим содержимое превращается в исполняемое поведение локального AI-агента. И снова ломается именно граница между «данными проекта» и «тем, что получает право стартовать процесс на машине пользователя».
Для разработчиков и команд это означает довольно приземленные вещи. Репозиторий больше нельзя считать просто набором исходников и манифестов для сборки. Если в компании используются AI-помощники с поддержкой MCP, агентных расширений или project-level настроек, то любой новый репозиторий надо рассматривать как источник потенциально исполняемой логики. Особенно если инженеры регулярно открывают внешние демо-проекты, шаблоны, pet-проекты кандидатов или код из issue и pull request. У безопасников здесь тоже прибавляется работы: нужно не только фильтровать зависимости и секреты, но и понимать, какие IDE-плагины умеют запускать локальные процессы по конфигу из workspace и как именно они просят согласие пользователя.
На уровне бизнеса история бьет по самому привлекательному обещанию AI-инструментов для разработки: «подключил плагин и сразу ускорил команду». Чем плотнее ассистент встроен в IDE, терминал, облачные CLI и внутренние API, тем выше его ценность и тем опаснее ошибка в модели доверия. Похоже, рынок еще только учится базовому правилу: конфиг из репозитория — это недоверенный ввод, даже если его читает дружелюбный помощник с красивой кнопкой в редакторе. И если для запуска MCP-сервера не требуется отдельное, явное и понятное подтверждение, это уже не удобство, а лишний способ подарить доступ к своей инфраструктуре тому, кто лучше всех оформил README.