Rockstar Games снова взломали: ShinyHunters потребовала выкуп до 14 апреля

Rockstar Games снова взломали: ShinyHunters потребовала выкуп до 14 апреля

Rockstar Games снова взломали: ShinyHunters потребовала выкуп до 14 апреля

Rockstar Games снова столкнулась с неприятным с киберинцидентом. На этот раз о взломе игрового гиганта заявила группировка ShinyHunters, участники которой получили доступ к данным компании и потребовали выкуп, пригрозив публикацией материалов после 14 апреля. Позже сам факт инцидента подтвердила и Rockstar.

По данным СМИ, атака была связана с компрометацией стороннего сервиса Anodot, который используется для аналитики и мониторинга.

Через него злоумышленники якобы смогли получить токены аутентификации и использовать их для доступа к инфраструктуре клиентов Snowflake, в число которых входила и Rockstar.

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

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

Что именно могла унести ShinyHunters, пока до конца не ясно. В публикациях о взломе речь идёт скорее о внутренней корпоративной информации, чем о данных игроков или критически важных материалах разработки. На этом фоне и сама формулировка Rockstar про «non-material company information» выглядит попыткой показать, что ущерб оказался ограниченным.

История особенно громкая ещё и потому, что это уже не первый подобный эпизод для Rockstar за последние годы. В 2022 году корпорация пережила крупную утечку, связанную с ранними материалами по GTA VI, так что нынешняя новость сразу вызвала у аудитории нервную реакцию, особенно на фоне ожидания новой части игры.

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