Уязвимость Amazon Q в расширении для Visual Studio Code позволяла атакующему украсть облачные учётные данные разработчика буквально после открытия вредоносного репозитория. Для российской IT-аудитории здесь важен не только сам баг, но и более неприятный вывод: AI-ассистенты для кода уже стали такой же критичной частью девелоперского стека, как браузер, IDE и SSH-ключи, а значит и атаковать их будут по-взрослому.
О проблеме 29 июня 2026 года сообщила Dark Reading. По данным издания, AWS исправила уязвимость высокой степени опасности в Amazon Q Developer: злоумышленнику было достаточно убедить разработчика открыть специально подготовленный репозиторий, чтобы добиться выполнения произвольного кода и добраться до секретов из текущей сессии. Речь шла не только об AWS credentials, но и об API-ключах, сокетах SSH-агента и других чувствительных данных, доступных окружению разработчика.
Уязвимость обнаружила команда Wiz Research. Баг получил идентификатор CVE-2026-12957 и, как следует из описания, был связан с тем, как Amazon Q работал с MCP, Model Context Protocol. Проблема заключалась в том, что расширение по умолчанию автоматически подхватывало и запускало конфигурации MCP-серверов из файлов рабочего пространства без отдельного подтверждения со стороны пользователя. Дальше начиналась классика новой AI-эпохи: дочерние процессы наследовали полное окружение разработчика, а вместе с ним и всё, что обычно лежит под рукой у человека с доступом к облаку, внутренним сервисам и продовым контурам.
Формально сценарий атаки выглядел почти буднично. Разработчик клонирует вредоносный репозиторий или пакет-двойник с опечаткой в названии, открывает папку в VS Code с установленным Amazon Q, после чего расширение загружает и исполняет вредоносную MCP-конфигурацию ещё до того, как человек успевает просмотреть код. Именно это делает историю неприятной: обычная привычка “сначала открою проект, потом разберусь” здесь превращается в точку компрометации. Исследователи Wiz проверили proof of concept и показали, что команда aws sts get-caller-identity позволяет захватить активную AWS-сессию разработчика. То есть путь от “просто открыл репозиторий” до “утекли облачные доступы” оказался не теоретическим, а вполне рабочим.
Дальше риски становятся уже инфраструктурными, а не локальными. Если злоумышленник получает контекст разработчика, он может закрепиться в облаке через IAM-пользователей и ключи, достучаться до внутренних сервисов через унаследованный сетевой доступ или VPN-контекст, а в худшем случае использовать заражённую среду как плацдарм для атаки на цепочку поставок. Особенно неприятен этот сценарий для команд, которые поддерживают популярные библиотеки, внутренние платформы или shared-компоненты. Один заражённый ноутбук разработчика в такой модели легко превращается в проблему не уровня “почистили рабочую станцию”, а в инцидент с затронутыми продуктами и клиентскими средами.
AWS закрыла уязвимость обновлением AWS Language Server до версии 1.65.0. Это важная деталь, потому что именно Language Server лежит под капотом AI-помощника Amazon Q в плагинах для Visual Studio Code, JetBrains, Eclipse и Visual Studio. Иными словами, история касается не только одного расширения в одной IDE, а более широкого куска экосистемы инструментов разработчика. Для тех, кто уже использует версию 1.65.0 и выше, немедленных действий источник не требует. Но само исправление не отменяет системную проблему: доверие к инструменту, который сидит внутри IDE и имеет доступ к рабочему окружению, сейчас зачастую выстроено по модели “это же наш помощник, а не потенциальный канал эксфильтрации”. Практика показывает, что пора менять оптику.
На этом месте история перестаёт быть сугубо про Amazon. Исследователь Wiz Маор Доханиан напрямую связывает инцидент с более широким паттерном в экосистеме AI coding tools. В материале упоминаются похожие находки у Claude Code, Cursor и Windsurf. Общая логика одинакова: автоматическое исполнение конфигураций рабочего пространства, завязанных на MCP или соседние механизмы, превращает удобство в уязвимость. И тут проблема уже не только в конкретном вендоре или неудачной реализации. MCP сегодня всё активнее используют как “клей” между AI-агентами и корпоративными системами, а значит любая ошибка в этой прослойке автоматически получает привилегии того, кто запускает инструмент. В случае разработчика привилегии обычно щедрые: облако, репозитории, секреты, CI/CD, иногда прод и почти всегда доступ к внутренней сети.
Для российских компаний, которые экспериментируют с AI-ассистентами в разработке, выводы довольно прикладные. Во-первых, такие инструменты уже нельзя считать просто “ещё одним плагином”, их нужно инвентаризировать и проверять как часть критической инфраструктуры рабочего места. Во-вторых, предупреждения об “недоверенном MCP-сервере” нельзя автоматически прокликивать, даже если дедлайн уже дышит в затылок. В-третьих, стоит отдельно аудитировать MCP-конфигурации и права, которые наследуют процессы AI-инструментов: где лежат ключи, какие переменные окружения доступны, что можно вызвать из CLI без повторной аутентификации, есть ли доступ к продовым аккаунтам из девелоперской машины. Наконец, сам процесс найма, ревью внешних pull request и работы с зависимостями стоит смотреть через призму этой модели угроз. Если вредоносный репозиторий можно подсунуть через фейковое тестовое задание или пакет с опечаткой в названии, значит атака отлично масштабируется и без голливудского уровня подготовки.
Главный вопрос теперь не в том, будут ли находить новые баги в AI-инструментах для разработчиков, а в том, кто быстрее перестроит к ним отношение: вендоры, которые по привычке делают ставку на бесшовный UX, или компании, которые пока ещё считают AI-помощника безобидным ускорителем. История с Amazon Q показывает, что компромисс между удобством и безопасностью уже закончился в пользу удобства, и рынок теперь будет расплачиваться за это патчами, аудитами и всё более жёсткими ограничениями на то, что AI-ассистенту вообще можно доверить.