MCP небезопасен по умолчанию: разбор command injection, tool poisoning и рисков утечки данных

В MCP нет встроенного понятия «это описание инструмента ненадёжно» или «этот сервер изменился с момента, когда вы его одобрили». Каждый риск в этой статье сводится к одному и тому же пробелу: ИИ-агент по умолчанию доверяет тому, что сообщает ему MCP-сервер, названиям инструментов, описаниям, выводу, как надёжному контексту, потому что ничто в протоколе не заставляет его относиться к этому контенту с большей подозрительностью, чем к собственным инструкциям пользователя.

Насколько это реально распространено

Оценка от марта 2025 года из security-компании Equixly нашла уязвимости command injection в 43% протестированных реализаций MCP-серверов, наряду с path traversal в 22% и SSRF, эксплуатируемым без аутентификации, в 30%. Стоит быть точным насчёт того, чем является и не является эта цифра: Equixly не опубликовала размер выборки или названия протестированных серверов, так что относитесь к 43% как к оценке вендора, указывающей на реальный, распространённый паттерн, а не как к рецензируемой ставке, которую можно цитировать как популяционную статистику. Сам паттерн, впрочем, стабильно проявляется в независимых исследованиях, и это важнее точного процента.

Названные категории риска простыми словами

Command injection. Сервер передаёт ввод от пользователя или агента в shell-команду или вызов подпроцесса без санитизации: тот же класс бага, что десятилетиями существует в веб-бэкендах, просто теперь сидящий за протоколом, с которым ИИ-агент говорит напрямую, а не через браузер.

Tool poisoning. Оригинальное раскрытие от Invariant Labs даёт точное определение: «вредоносные инструкции, встроенные в описания MCP-инструментов, невидимые для пользователей, но видимые для ИИ-моделей» (в оригинале: "malicious instructions embedded within MCP tool descriptions that are invisible to users but visible to AI models"). Название и описание инструмента это метаданные, которые человек, одобряющий подключение, видит один раз. Модель видит те же метаданные при каждом отдельном вызове, поэтому описание, составленное так, чтобы говорить одно человеку и совсем другое модели, это долговременная поверхность атаки, а не одноразовый трюк.

Rug pull. То же раскрытие описывает и это: «вредоносный сервер может изменить описание инструмента после того, как клиент его уже одобрил» (в оригинале: "a malicious server can change the tool description after the client has already approved it"). Одобрение происходит один раз, в момент подключения. Ничто в базовом протоколе повторно не проверяет, что инструмент всё ещё делает то, что было заявлено при одобрении, а значит сервер может вести себя корректно во время проверки и изменить поведение после неё.

Tool shadowing. Вредоносный сервер регистрирует инструмент, который пересекается с инструментом другого, доверенного сервера, к которому тот же агент уже подключён, или встраивает инструкции, меняющие поведение вокруг него. Атаке вообще не нужно компрометировать доверенный сервер. Нужно только, чтобы агент оказался не уверен, какое именно определение инструмента исполнять.

Косвенная инъекция промпта. Инструкции, встроенные в контент, который возвращает инструмент, файл, веб-страница, строка в базе данных, модель читает с тем же доверием, что и прямую инструкцию от пользователя, потому что ничто не помечает возвращённый контент как данные, а не как инструкции.

Реальный пример, а не гипотетический

CVE-2025-54136 с прозвищем «MCPoison», CVSS 8.8, это rug pull, который реально произошёл, а не теоретическая категория. Исследователи Check Point обнаружили, что Cursor доверял уже одобренной конфигурации MCP-сервера даже после того, как команда, на которую она указывала, была подменена уже после одобрения, что позволяло атакующему с доступом на изменение общей конфигурации MCP в репозитории незаметно перенаправить ранее доверенный инструмент на выполнение чего-то совсем другого. Сообщено в Cursor 16 июля 2025 года, исправлено в Cursor 1.3 29 июля 2025 года. Это общий паттерн rug pull выше, только против конкретного, широко используемого клиента, с присвоенным номером CVE.

Практический чек-лист по снижению риска

Ничто из этого не требует отказа от MCP. Требуется относиться к контенту, предоставленному сервером, так же, как security-осознанная команда уже относится к любому другому ненадёжному вводу:

• Закреплять сервер, а не только сам факт подключения. Одобрить инструмент один раз не то же самое, что доверять его описанию навсегда. Там, где клиент это поддерживает, проверяйте, что определение инструмента не изменилось с момента одобрения, вместо того чтобы бесконечно доверять первоначальной проверке.
• Санитизировать и валидировать каждый ввод, который принимает схема инструмента, на стороне сервера: та же дисциплина, которую command injection требовал от любого бэкенда двадцать лет, теперь применённая к поверхности, которую агент вызывает напрямую.
• Относиться к выводу инструмента как к данным, а не инструкциям, особенно к контенту, который инструмент забирает откуда-то за пределами вашего собственного контроля: загруженной странице, ответу стороннего API, файлу, который агент не писал сам.
• Ограничивать, до чего реально может дотянуться подключённый сервер. Тарификация риска в момент выполнения и скоупинг доступа по действию, окружению и времени удерживают радиус поражения от скомпрометированного или отравленного инструмента в рамках того, что разрешает токен конкретно этого агента, а не того, что технически способен сделать базовый credential.
• Следить за сервером, меняющим поведение между проверкой и использованием, а не только в момент первого подключения. Вся посылка rug pull в том, что опасная версия появляется только после того, как безопасную уже одобрили.

Сама спецификация MCP ничего из этого не решает по умолчанию, тот же пробел, который собственная спецификация оркестрации Symphony честно оставляет на усмотрение того, кто её реализует, только на уровне диспетчеризации. «Небезопасен по умолчанию» это не повод избегать протокола. Это повод не считать подключение к MCP-серверу решённой проблемой безопасности только потому, что само подключение оказалось лёгким.