AWS закрыла две уязвимости в MCP-серверах для PostgreSQL и DynamoDB

Два разных пути от контента к побочному эффекту

AWS опубликовала два бюллетеня об уязвимостях в open-source MCP-серверах awslabs. CVE-2026-85787 относится к проверке SQL в postgres-mcp-server, а CVE-2026-85654 — к шаблонизации в CDK-генераторе dynamodb-mcp-server. В обоих случаях опасным становилось содержимое, которое внешне выглядело как обычный ввод для помощника или генератора.

Уязвимости затрагивают не управляемые базы данных как таковые, а программные MCP-компоненты, соединяющие AI coding assistants с PostgreSQL и DynamoDB. Это различие важно для оценки риска: наличие базы AWS не означает автоматическую уязвимость. Проверять нужно, используется ли конкретный пакет, какая версия установлена, с какими полномочиями он запущен и выполняется ли сгенерированный им код.

Оба бюллетеня AWS помечены как Important и датированы 4 сентября 2026 года. Для PostgreSQL исправленной границей является версия 1.1.7, для DynamoDB — 2.1.6. Простое обновление закрывает известные дефекты, но рекомендации AWS показывают, что архитектура прав остаётся обязательной второй линией защиты.

PostgreSQL: read-only нельзя обеспечивать одним блок-листом

CVE-2026-85787 затрагивает версии PyPI-пакета awslabs.postgres-mcp-server ниже 1.1.7. По описанию AWS, неполный список запрещённых вводов в компоненте проверки SQL мог позволить неаутентифицированному участнику поместить специально подготовленный SQL в контент, который обрабатывается при взаимодействии аутентифицированного пользователя с MCP-сервером. Результатом могло стать изменение данных за пределами заявленного режима read-only.

Здесь граница доверия проходит не только через сетевую аутентификацию. Злоумышленнику не обязательно иметь собственный доступ к базе, если вредоносное содержимое попадёт в рабочий контекст пользователя, а агент затем передаст его инструменту. Аутентифицированная сессия становится проводником полномочий, поэтому проверка того, кто подключился, не заменяет проверку того, что разрешено конкретному процессу.

AWS рекомендует запускать сервер под отдельной PostgreSQL-ролью с минимальными правами. Для чтения это CONNECT, USAGE и SELECT только на необходимых схемах, дополненные принудительным read-only на уровне роли. Компания прямо предостерегает от superuser, rds_superuser и cluster master: такие роли способны обходить ограничения, читать чувствительные каталоги и завершать чужие сессии.

Практический вывод состоит в разделении двух механизмов. Проверка SQL на уровне приложения отсекает известные опасные формы ввода и даёт понятную ошибку. Права базы обеспечивают окончательную границу: даже если новая конструкция минует валидатор, роль без UPDATE, INSERT или DELETE не должна получить возможность изменить таблицу. AWS называет сочетание блок-листа и минимальной роли многоуровневой защитой.

DynamoDB: декларативный файл оказался исполняемым вводом

CVE-2026-85654 затрагивает awslabs.dynamodb-mcp-server версий от 2.0.10 до 2.1.5 включительно. AWS обнаружила ненадлежащую нейтрализацию специальных элементов в шаблонизаторе CDK-генератора. При определённых условиях специально сформированные имена таблиц, индексов или атрибутов в файле модели данных могли привести к выполнению произвольного кода на машине, где развёртывают сгенерированное приложение.

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

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

Инвентаризация, обновление и ограничение последствий

Первый шаг для команды — найти не только явно зарегистрированные MCP-серверы, но и локальные установки у разработчиков и форки исходных репозиториев. Для каждого экземпляра нужны владелец, пакет, версия, способ запуска, используемые учётные данные и перечень доступных ресурсов. Без такого реестра публикация исправления не отвечает на главный вопрос: где именно оно должно быть применено.

Второй шаг — обновить postgres-mcp-server до 1.1.7 или новее и dynamodb-mcp-server до 2.1.6 или новее, затем проверить, что внутренние форки действительно включили исправления. Номер версии в исходном репозитории, образе контейнера и запущенном процессе может различаться, поэтому проверка должна доходить до runtime-экземпляра.

Третий шаг — ограничить последствия возможного следующего дефекта. Сервер чтения не должен иметь права записи; генерация кода должна выполняться в изолированной среде; изменения в сгенерированном проекте должны быть видимы до развёртывания; учётные данные CI должны быть ограничены целевым окружением. Эти меры полезны даже после патча, потому что устраняют предположение, будто вся цепочка от документа до вызова инструмента всегда будет безошибочной.

Два бюллетеня показывают общую проблему агентской инфраструктуры: текст, записи базы и файлы схемы нельзя считать пассивными только из-за их формата. MCP сокращает расстояние между содержимым и системным действием. Поэтому безопасная реализация должна одновременно проверять ввод, обновлять компоненты, обеспечивать минимальные права на уровне ресурса и сохранять понятный журнал перехода от контента к выполненной операции.