Уязвимость Amazon Q с идентификатором CVE-2026-12957 и оценкой 8,5 по CVSS 4.0 превращала обычное открытие Git-репозитория в риск для всей облачной среды разработчика. Если инженер запускал Amazon Q в Visual Studio Code внутри специально подготовленного проекта, ассистент мог выполнить чужую команду на локальной машине и утащить уже загруженные AWS-учётные данные, токены и ключи.
Проблема затронула интеграцию Amazon Q для VS Code и, как пишет The Register, была связана с обработкой конфигураций MCP-серверов. Исследователи из Wiz обнаружили, что расширение автоматически подхватывало файл .amazonq/mcp.json из рабочей директории и исполняло команды, указанные в нём, после открытия проекта и активации помощника. Ключевой сбой не в самом факте запуска локальных процессов: MCP как раз для этого и нужен. Ошибка в том, что механизм, который по идее должен требовать осознанного согласия пользователя, срабатывал без запроса, без проверки доверия к рабочему пространству и без явного подтверждения.
Для разработчика это не косметический баг и не спор вокруг UX. MCP, или Model Context Protocol, всё чаще используют AI-ассистенты для доступа к локальным инструментам, скриптам и сервисам. В случае Amazon Q такие процессы наследовали окружение пользователя. А значит, вместе с возможностью выполнить команду злоумышленник получал шанс дотянуться до того, что уже лежит в сессии: AWS credentials, API-ключи, токены аутентификации, сокеты SSH-агента и прочие секреты, которые обычно живут рядом с инженером и редко считаются чем-то экзотическим. Wiz показала рабочую атаку на практике: исследователи собрали репозиторий с вредоносной MCP-конфигурацией, и после его открытия Amazon Q выполнил команду к AWS с использованием текущих учётных данных разработчика.
Amazon закрыла дыру в версии 1.65.0 language server, который лежит под IDE-интеграциями Amazon Q. По данным компании, обновление должно разойтись автоматически, если у пользователя не отключены автoапдейты. Это важная деталь: в подобных историях уязвимость живёт не только в коде, но и в инерции рабочих станций. Если где-то в команде обновления IDE-компонентов заморожены, старый билд превращается в тихий вход для атаки через seemingly harmless репозиторий. Для команд с большим числом подрядчиков, тестовых машин и временных окружений это особенно неприятный сценарий: достаточно одного инженера, который откроет не тот проект.
Но ещё важнее другой вывод, на котором настаивает Wiz: уязвимость Amazon Q выглядит не как единичный промах Amazon, а как симптом более широкого тренда. AI-инструменты для разработки всё активнее получают право запускать локальные команды и работать с конфигурацией прямо из проекта. Для продуктивности это удобно: меньше ручной настройки, быстрее подключение инструментов, проще автоматизировать рутину. Для безопасности это означает, что скрытые служебные файлы внутри репозитория становятся новой зоной атаки. Раньше разработчик, открывая чужой код, в первую очередь думал о зависимостях, postinstall-скриптах и макросах в документах. Теперь к этому списку добавляются конфиги AI-ассистентов, которые могут выглядеть как техническая мелочь, но фактически управляют выполнением команд на машине.
Для русскоязычной IT-аудитории здесь несколько практических последствий. Во-первых, проверка dotfiles в репозитории перестаёт быть паранойей и становится нормой. Папки вроде .amazonq, файлы конфигурации MCP и любые проектные настройки AI-помощников нужно рассматривать так же внимательно, как .github/workflows, package.json или shell-скрипты bootstrap-процесса. Во-вторых, модель доверия к AI-ассистентам придётся пересобрать. Если инструмент умеет запускать локальные процессы, он уже не просто «умный autocomplete», а привилегированный посредник между кодом, терминалом и облаком. В-третьих, бизнесу придётся наводить порядок в базовой гигиене: минимальные привилегии для облачных ролей, короткоживущие токены, отдельные профили для разработки, контроль автозагрузки расширений и политика доверенных репозиториев.
Для CISO, DevSecOps и тимлидов эта история неприятна ещё и тем, что атака ложится на повседневный сценарий, который трудно запретить без ущерба для скорости работы. Никто не хочет объяснять команде, что теперь любой внешний proof-of-concept, тестовый репозиторий от вендора или демо от партнёра надо открывать почти как исполняемый файл из письма. Но именно к этому рынок и подталкивает. AI-помощники постепенно получают права, которые раньше отдавали только вручную настроенным локальным инструментам, а интерфейс при этом остаётся обманчиво дружелюбным. Кнопка «активировать ассистента» выглядит невинно, хотя за ней может стоять доступ к тем же секретам, что и у терминала разработчика.
Уязвимость Amazon Q в итоге интересна не только патчем до версии 1.65.0 и не только конкретным CVE. Она показывает, как быстро меняется поверхность атаки в разработке: опасными становятся не только зависимости и CI/CD, но и конфигурации, которые AI-инструменты считают частью удобного контекста проекта. Чем глубже ассистенты встраиваются в IDE и локальное окружение, тем жёстче индустрии придётся отвечать на простой вопрос: кто именно дал репозиторию право что-то запускать на машине инженера и почему это право вообще появилось без отдельного разговора с пользователем.