Telegram MCP-сервер fast-mcp-telegram пустил атакующих к телеграм-сессии

Telegram MCP-сервер fast-mcp-telegram пустил атакующих к телеграм-сессии

Telegram MCP-сервер fast-mcp-telegram пустил атакующих к телеграм-сессии

В fast-mcp-telegram нашли критическую уязвимость под идентификатором CVE-2026-52830: хотели защититься токенами bearer, а в итоге превратили токен в путь к файлу. В результате атакующий может получить доступ к MCP-сессии Telegram по HTTP без валидного закрытого токена.

Fast-mcp-telegram — это MCP-сервер, который подключает телеграм-аккаунты к ИИ-ассистентам и HTTP-клиентам через сессионную модель аутентификации.

В версиях до 0.19.0 включительно проверка токена устроена так: сервер берёт строку из Authorization: Bearer, добавляет к ней .session, склеивает с директорией сессий и проверяет, существует ли такой файл.

Проблема в том, что токен не нормализуется как безопасный идентификатор. Код запрещает некоторые зарезервированные имена, например telegram, но не блокирует слеши, «..», абсолютные пути и другие конструкции.

Вместо закрытого ключа сервер фактически принимает относительный путь в файловой системе. Отличный подарок для атакующего, плохая новость для владельца телеграм-аккаунта.

В типичной конфигурации дефолтная сессия лежит в файле ~/.config/fast-mcp-telegram/telegram.session. Прямой токен telegram отклоняется, но обходной вариант вроде ../fast-mcp-telegram/telegram может схлопнуться файловой системой в тот же самый файл. Если файл существует, сервер принимает такой токен и аутентифицирует атакующего как дефолтный телеграм-аккаунт.

После этого злоумышленник может читать и отправлять сообщения, вызывать MTProto API и использовать доступные инструменты, привязанные к этой сессии. Защита на уровне префиксов инструментов тут уже не спасает: она срабатывает после аутентификации, а дверь к аккаунту к тому моменту уже открыта.

Уязвимость затрагивает fast-mcp-telegram до версии 0.19.0 включительно. В версии 0.19.1 разработчики ужесточили проверку и начали обращаться с bearer-токенами как с непрозрачными идентификаторами, а не как с кусками пути.

Администраторам рекомендуют срочно обновиться, ротировать дефолтные и старые session-файлы, а также проверить логи на подозрительные bearer-значения со слешами и «…».

15 тыс. отправили ИИ-агентов на борьбу с кибератаками

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

Такие данные представила Yandex Cloud в отчёте об угрозах для облачных и гибридных инфраструктур за первое полугодие 2026 года.

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

В российских облаках фиксировались попытки использовать критическую уязвимость React2Shell, а также проблемы ядра Linux Copy Fail и Dirty Frag.

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

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

В Yandex Cloud считают, что современным корпоративным системам защиты необходимы поведенческие детекторы, объединённая телеметрия и ИИ-агенты. Причина проста: атаки ускоряются, а классическая схема «получили алерт — открыли тикет — когда-нибудь посмотрели» всё чаще проигрывает злоумышленникам по темпу.

Поменялись и главные цели. В первой половине 2025 года 35% атак приходилось на ИТ-компании. К середине 2026 года на первое место вышел ретейл с долей 39%, следом расположилось производство с 29%, а ИТ-сектор опустился до 20%.

RSS: Новости на портале Anti-Malware.ru