Минцифры: искусственный интеллект в России нужно подвергнуть цензуре

Минцифры: искусственный интеллект в России нужно подвергнуть цензуре

Минцифры: искусственный интеллект в России нужно подвергнуть цензуре

В России обсуждают, каким должен быть «правильный» искусственный интеллект и, похоже, без ограничений его видеть не хотят. Замглавы Минцифры Александр Шойтов на форуме «ИИ: режим доверия» заявил, что ИИ в стране должен работать с цензурными ограничениями и «на входе, и на выходе», чтобы отсекать нежелательные и чувствительные запросы.

По его словам, нейросети в этом смысле нельзя ставить в один ряд с человеком, потому что «людей у нас цензурировать нельзя, у них есть права».

По сути, речь идёт о модели, при которой ИИ-системы должны заранее фильтровать часть запросов пользователей и ограничивать определённые ответы. Такая позиция выглядит как продолжение линии Минцифры на более жёсткое регулирование нейросетей: ещё в марте ведомство вынесло на общественное обсуждение законопроект о регулировании ИИ в России.

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

На этом фоне курс государства в целом выглядит двойственным, но вполне понятным: ИИ собираются активно внедрять, но одновременно держать под контролем. 10 апреля Владимир Путин поручил правительству совместно с регионами подготовить национальный план внедрения искусственного интеллекта.

Президент отдельно подчеркнул, что к 2030 году ИИ должен широко использоваться в ключевых сферах — от промышленности и логистики до образования, энергетики и госуправления. При этом, по его словам, регулирование не должно душить развитие отрасли, иначе страна рискует отстать в технологиях и экономике.

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

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-значения со слешами и «…».

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