Сразу три уязвимости MCP обнаружили в серверах для работы с базами данных Apache Doris, Apache Pinot и Alibaba RDS. В одном случае уже есть CVE и исправление, во втором проблему только обсуждают, в третьем вендор вообще отказался выпускать патч. Для команд, которые подключают LLM и агентные системы к продовым данным, это плохой сигнал: слой между моделью и базой все еще слишком часто собирают по принципу «сначала заработает, потом защитим».
О проблемах сообщает The Register со ссылкой на исследование аналитика Akamai Томера Пеледа. Он изучил MCP-серверы для популярных СУБД и пришел к неприятному выводу: у разных проектов повторяются одни и те же базовые ошибки — слабая валидация запросов, отсутствие обязательной аутентификации и слишком доверительное отношение к клиенту, который добрался до MCP-эндпоинта.
Самый конкретный кейс касается Apache Doris MCP Server. Для него уже зарегистрирована уязвимость CVE-2025-66335, затрагивающая версии ниже 0.6.1. Проблема в функции exec_query: один из пяти параметров, db_name, не проходит должную проверку перед сборкой SQL-запроса. По словам исследователя, атакующий может подставить в этот параметр собственный SQL, а встроенный валидатор проверит только первую часть строки и фактически «не заметит» инъекцию дальше по тексту. Итог — выполнение произвольных команд в экземпляре Apache Doris, если злоумышленник получил доступ к клиенту, связанному с MCP-сервером. Apache, в отличие от многих участников AI-гонки, здесь сработал нормально: еще в декабре выпустил патч.
С Apache Pinot ситуация менее аккуратная. По данным исследования, уязвимы Pinot MCP версии 1.1.0 и ниже. Интеграция StarTree позволяла AI-агенту отправлять запросы в Pinot напрямую, а в качестве транспортного слоя использовался HTTP без обязательной аутентификации. Если такой MCP-эндпоинт доступен извне, любой удаленный атакующий может вызвать инструменты MCP, в том числе связанные с выполнением SQL-запросов. Пелед пишет, что в такой конфигурации риск доходит до полного удаленного захвата базы. StarTree после этого добавила OAuth как вариант аутентификации для HTTP, что снижает риск эксплуатации, но, по словам исследователя, сам корень проблемы в коде до конца не исчез. В репозитории MCP Pinot уже открыт security-ticket, однако полноценного исправления на момент публикации не было.
Почему это не частный баг, а симптом
Третий случай особенно показателен, потому что дело не только в самой дыре, но и в реакции вендора. У Alibaba RDS MCP уязвимы все версии, которые изучал исследователь. Проблема связана с тем, что сервер не аутентифицирует пользователя перед вызовом RAG-инструмента MCP. Это означает, что любой клиент, способный достучаться до конечной точки, может отправлять запросы без валидации и вытягивать данные из векторного индекса. А там могут лежать названия таблиц, описания схем и другая чувствительная метаинформация. То есть речь не про абстрактную «утечку контекста», а про вполне прикладную разведку по внутреннему устройству базы. Пелед сообщил о проблеме Alibaba еще в ноябре, но, по его словам, компания ответила, что баг «неприменим» для исправления. После этого Akamai уведомила CERT/CC.
Здесь важна не только реакция конкретной компании, но и общий контекст. MCP, или Model Context Protocol, изначально задумывался как универсальный способ подключать модели, AI-приложения и агентов к внешним системам. Идея понятная: меньше кастомной интеграции, больше стандартизации. На практике же стандарт оказался достаточно молодым, а реализация у разных команд живет по своим правилам. Исследователь Akamai прямо говорит, что ожидал увидеть хотя бы базовую security-спецификацию для MCP-серверов. Не увидел. Поэтому в коде всплыли проблемы из старого учебника по AppSec: SQL-инъекции, отсутствие аутентификации, недостаточная проверка запроса. Разница лишь в том, что теперь такой сервер стоит между LLM и производственной БД, а значит цена ошибки выше.
Для русскоязычной IT-аудитории вывод приземленный и неприятный. Если компания внедряет copilots, внутренних ассистентов или агентные сценарии поверх аналитических хранилищ, сам факт использования MCP нельзя считать гарантией безопасности. Проверять нужно не только модель, промпты и права доступа в базе, но и весь промежуточный слой: какие инструменты экспортируются через MCP, есть ли аутентификация на HTTP-уровне, как валидируются параметры запросов, доступен ли эндпоинт из внешней сети, что лежит в RAG-индексе и можно ли оттуда вытащить метаданные без логина. Иначе в архитектуре появляется очень удобный шорткат: не ломать БД напрямую, а зайти через «умного помощника», которому уже дали ключи и почти ни о чем не спросили.
Что это значит для рынка AI-интеграций
Уязвимости MCP бьют ровно по той зоне, где сейчас больше всего энтузиазма и меньше всего инженерной дисциплины. Бизнес хочет, чтобы агент умел ходить в базу, строить отчеты, отвечать на вопросы по схеме данных и выполнять запросы «на человеческом языке». Разработчики собирают это быстро, потому что рынок подталкивает к скорости. В результате MCP-сервер часто воспринимают как нейтральный коннектор, хотя по факту это привилегированный шлюз к данным и операциям. Если в нем нет жесткой аутентификации и нормальной валидации, то любая красивая демка с AI-агентом внезапно превращается в еще одну точку входа для атаки.
Главный вопрос теперь не в том, найдут ли новые уязвимости MCP, а в том, успеют ли разработчики протокола и интеграторы договориться о минимальном security-baseline раньше, чем такие серверы станут массовой частью корпоративного стека. Пока картина выглядит так: один проект выпустил патч, второй добавил частичную защиту, третий решил, что проблемы нет. Для технологии, которая претендует на роль стандартного интерфейса между AI и внутренними системами, это слишком сырой уровень зрелости. Подробности исследования собраны в материале .