В Amazon Q нашли опасную уязвимость для разработчиков

В Amazon Q Developer нашли уязвимость, которая могла превратить обычное открытие репозитория в компрометацию облачных ключей. Проблема получила идентификатор CVE-2026-12957 и связана с неправильной границей доверия в Language Servers for AWS — языковых серверах, которые используются в плагинах Amazon Q Developer для популярных сред разработки.

Сценарий атаки выглядел так: разработчик открывает специально подготовленный workspace, например тестовое задание, pull request, пример проекта или библиотеку из открытого репозитория. Если среда считает проект доверенным, команды из конфигурационных файлов могут выполниться автоматически. Дальше всё зависит от того, какие права и секреты есть на машине: AWS-профили, переменные окружения, токены CI/CD, ключи других облаков, доступ к внутренним пакетам, GitHub-токены.

AWS исправила проблему и выпустила обновления. Под удар попадали Language Servers for AWS до версии 1.69.0, Amazon Q Developer для Visual Studio Code до версии 2.20, JetBrains до версии 4.3, Eclipse до версии 2.7.4 и AWS Toolkit with Amazon Q для Visual Studio до версии 1.94.0.0. Отдельного обходного решения нет — нужно обновляться.

Amazon Q Developer — ИИ-помощник для разработчиков. Он умеет подсказывать код, объяснять фрагменты, помогать с рефакторингом, работать с проектом внутри IDE и взаимодействовать с локальными инструментами. 

Корень CVE-2026-12957 — неправильное разделение доверенной и недоверенной зоны. Языковой сервер мог автоматически действовать на основе конфигурации, которая лежит внутри открытого workspace. Если проект был вредоносным, в конфигурационных файлах можно было спрятать команды, которые запускались без нормального пользовательского контроля.

Это особенно опасно для разработчиков, уже вошедших в AWS или другие облачные сервисы. В реальной работе у них часто есть активные профили, временные ключи, токены сессий, переменные окружения, доступ к контейнерным реестрам, инфраструктурным шаблонам и внутренним пакетам.

Вторая уязвимость, CVE-2026-12958, связана с обработкой символических ссылок. Символическая ссылка — это файл-указатель, который ведёт на другой путь в системе. Если инструмент плохо проверяет такие ссылки, проект может «вывести» обработку за пределы своей папки и добраться до того, что не должно попадать в область работы workspace.

В связке такие ошибки неприятны для IDE-плагинов: одна проблема касается запуска команд, вторая — границ файлового пространства.

Самый реалистичный сценарий — вредоносное тестовое задание. Разработчику присылают ссылку на репозиторий: «посмотрите код», «почините баг», «выполните задачу для собеседования», «оцените pull request». Это уже привычный формат работы, поэтому подозрений мало.

Другой вариант — вредоносный pull request в популярный проект. Мейнтейнер или контрибьютор открывает ветку локально, чтобы проверить изменения. Внутри лежит конфигурация, которая срабатывает при открытии проекта.

Третий вариант — typosquatting и поддельные open source-пакеты. Репозиторий выглядит как похожий на известный проект, но содержит ловушку. Разработчик скачивает пример, открывает его в IDE, а дальше всё делает локальная автоматизация.

Если в окружении есть облачные ключи, злоумышленник может попытаться вытащить их наружу. Если права широкие, риск выходит за пределы ноутбука. Под угрозой оказываются бакеты, функции, контейнеры, секреты, CI/CD, инфраструктура как код и внутренние сервисы.

AWS выпустила исправления для Language Servers for AWS и соответствующих плагинов Amazon Q Developer. Уязвимости закрыты в Language Servers for AWS 1.69.0. Для пользователей это означает необходимость обновить IDE-плагины до свежих версий.

Обновления затрагивают Amazon Q Developer для Visual Studio Code, JetBrains, Eclipse и Visual Studio. В большинстве обычных сценариев языковой сервер обновляется автоматически, но это может не сработать в корпоративной сети, где обновления расширений заблокированы, IDE работает в изолированном контуре или плагины ставятся через внутренний каталог.

Именно такие окружения стоит проверить отдельно. В компании может казаться, что «всё обновляется само», но корпоративный прокси, замороженные версии плагинов или golden image для рабочих станций часто ломают эту уверенность.