Июнь 2026 года принёс одну из самых показательных уязвимостей эпохи AI-кодинга. Исследователи Wiz Research обнаружили, что встроенный в Amazon Q Developer механизм чтения конфигурации Model Context Protocol (MCP) превращает обычное открытие репозитория в «доверенном» режиме IDE в запуск произвольного кода с правами текущего пользователя — со всеми его AWS-ключами, CLI-токенами и сокетами SSH-агента. Дыра получила идентификатор CVE-2026-12957 и оценку CVSS 8.5 («High»). Параллельно в тот же релиз вошло исправление ещё одной ошибки — CVE-2026-12958 (отсутствие проверки символических ссылок), позволявшей писать файлы за пределами разрешённой директории рабочего пространства.
Как выглядит атака на практике? Разработчик клонирует «чистый» на вид публичный репозиторий, открывает его в VS Code, JetBrains IDE, Eclipse или Visual Studio с установленным плагином Amazon Q, соглашается с предложением IDE доверять рабочему каталогу. Дальше всё делает код. В корне проекта лежит файл
Корень проблемы — в общем компоненте Language Servers for AWS, на котором работает Amazon Q во всех поддерживаемых IDE. Один уязвимый модуль означает компрометацию сразу четырёх платформ: Microsoft VS Code (нужен плагин версии 2.20 или выше), JetBrains (IntelliJ, PyCharm и остальные — 4.3+), Eclipse (2.7.4+) и Visual Studio Toolkit (1.94.0.0+). Сами языковые серверы обновляются автоматически через встроенный механизм, если сеть не блокирует обновления, после чего достаточно перезагрузить IDE. Amazon рекомендует целевой апгрейд на Language Servers for AWS 1.69.0 — этот релиз закрывает обе CVE. Первая заплатка на CVE-2026-12957 вышла в версии 1.65.0.
Хронология раскрытия стандартная для белого хакинга в крупных компаниях: 20 апреля 2026 года Wiz Research отправили репорт в Amazon, 12 мая вендор выпустил исправление, а 26 июня появился публичный разбор. CISA включила уязвимость в свою базу ADP со статусом «none» — публичной эксплуатации на момент раскрытия зафиксировано не было.
Отдельный нерв — спор о модели согласия. Amazon в официальном бюллетене упирает на то, что пользователь сам подтверждает доверие рабочему пространству, и CVSS-оценка взаимодействия с пользователем помечена как «пассивная». Wiz Research отвечают просто и жёстко: до патча не существовало отдельного шага согласия именно на запуск MCP-серверов. Доверие к каталогу и согласие на исполнение произвольных процессов — это разные вещи. После фикса Amazon Q стал помечать ненадёжные MCP-серверы и требовать явного подтверждения разработчика перед запуском.
Инцидент вписывается в чёткую цепочку однотипных находок последних полутора лет. Claude Code в 2025-м (CVE-2025-59536), Cursor тогда же (CVE-2025-54136), Windsurf в 2026-м (CVE-2026-30615) — все страдали от того же архитектурного греха: проектный конфигурационный файл AI-агента автоматически превращался в исполняемое поведение. Баги не идентичные, но рифмуются. Удобство «конфигурации из репозитория» в AI-ассистентах создаёт готовую поверхность атаки, потому что доверие к коду перестаёт быть доверием к среде исполнения tambuровщика.
Для защиты нужны три простых шага. Поднять Language Servers for AWS до версии 1.69.0 или выше и проверить минимальные версии плагинов во всех IDE компании. Настроить сканеры секретов и политик так, чтобы любой файл
За этой историей стоит более широкий сдвиг: общие компоненты AI-инструментов создают одиночные точки отказа во всей экосистеме IDE, а модель бинарного доверия к каталогу файлов плохо подходит для агентов с возможностью исполнения кода. Когда CISA начинает вести подобные CVE в ADP, это сигнал регуляторам — AI-инструменты разработчика уже рассматриваются как часть критической инфраструктуры, и подход «доверяй всему, что лежит в репозитории», окончательно перестаёт быть безопасным.
Как выглядит атака на практике? Разработчик клонирует «чистый» на вид публичный репозиторий, открывает его в VS Code, JetBrains IDE, Eclipse или Visual Studio с установленным плагином Amazon Q, соглашается с предложением IDE доверять рабочему каталогу. Дальше всё делает код. В корне проекта лежит файл
.amazonq/mcp.json. Amazon Q автоматически разбирает его при старте сессии, запускает описанные в нём MCP-серверы как обычные локальные процессы — и эти процессы наследуют переменные окружения пользователя целиком: ключи доступа AWS, секретные ключи, токены облачных CLI, API-секреты, сокеты SSH-агента. Поскольку всё исполняется от имени разработчика, ничего подозрительного в системе не происходит. PoC исследователей запускал одну простую команду — aws sts get-caller-identity — и отправлял результат на внешний сервер, фиксируя активную сессию AWS. Дальше — дело техники и разрешений конкретного аккаунта: бэкдоринг IAM-пользователя, доступ ко внутренним сервисам, боковое перемещение в продакшн-среду. Корень проблемы — в общем компоненте Language Servers for AWS, на котором работает Amazon Q во всех поддерживаемых IDE. Один уязвимый модуль означает компрометацию сразу четырёх платформ: Microsoft VS Code (нужен плагин версии 2.20 или выше), JetBrains (IntelliJ, PyCharm и остальные — 4.3+), Eclipse (2.7.4+) и Visual Studio Toolkit (1.94.0.0+). Сами языковые серверы обновляются автоматически через встроенный механизм, если сеть не блокирует обновления, после чего достаточно перезагрузить IDE. Amazon рекомендует целевой апгрейд на Language Servers for AWS 1.69.0 — этот релиз закрывает обе CVE. Первая заплатка на CVE-2026-12957 вышла в версии 1.65.0.
Хронология раскрытия стандартная для белого хакинга в крупных компаниях: 20 апреля 2026 года Wiz Research отправили репорт в Amazon, 12 мая вендор выпустил исправление, а 26 июня появился публичный разбор. CISA включила уязвимость в свою базу ADP со статусом «none» — публичной эксплуатации на момент раскрытия зафиксировано не было.
Отдельный нерв — спор о модели согласия. Amazon в официальном бюллетене упирает на то, что пользователь сам подтверждает доверие рабочему пространству, и CVSS-оценка взаимодействия с пользователем помечена как «пассивная». Wiz Research отвечают просто и жёстко: до патча не существовало отдельного шага согласия именно на запуск MCP-серверов. Доверие к каталогу и согласие на исполнение произвольных процессов — это разные вещи. После фикса Amazon Q стал помечать ненадёжные MCP-серверы и требовать явного подтверждения разработчика перед запуском.
Инцидент вписывается в чёткую цепочку однотипных находок последних полутора лет. Claude Code в 2025-м (CVE-2025-59536), Cursor тогда же (CVE-2025-54136), Windsurf в 2026-м (CVE-2026-30615) — все страдали от того же архитектурного греха: проектный конфигурационный файл AI-агента автоматически превращался в исполняемое поведение. Баги не идентичные, но рифмуются. Удобство «конфигурации из репозитория» в AI-ассистентах создаёт готовую поверхность атаки, потому что доверие к коду перестаёт быть доверием к среде исполнения tambuровщика.
Для защиты нужны три простых шага. Поднять Language Servers for AWS до версии 1.69.0 или выше и проверить минимальные версии плагинов во всех IDE компании. Настроить сканеры секретов и политик так, чтобы любой файл
.amazonq/mcp.json в клонируемом репозитории сразу попадал в зону внимания — как раньше ловили левые package.json или подозрительные .github/workflows. И донести до разработчиков разницу между «я доверяю этому воркспейсу» и «я разрешаю запуск локальных процессов, описанных в чужом конфиге». За этой историей стоит более широкий сдвиг: общие компоненты AI-инструментов создают одиночные точки отказа во всей экосистеме IDE, а модель бинарного доверия к каталогу файлов плохо подходит для агентов с возможностью исполнения кода. Когда CISA начинает вести подобные CVE в ADP, это сигнал регуляторам — AI-инструменты разработчика уже рассматриваются как часть критической инфраструктуры, и подход «доверяй всему, что лежит в репозитории», окончательно перестаёт быть безопасным.