Kimi K3 собрала Redis-эксплойт, но не открыла новый zero-day

Исследователь безопасности Чаофань Шоу сообщил, что система из 32 агентов на базе Kimi K3 за 27 минут нашла ошибку в Redis и построила рабочую цепочку удалённого выполнения кода. Опубликованный репозиторий действительно содержит доказательство эксплуатации Redis 8.8.0 через обработчик TDigest в модуле RedisBloom.

Эксплойт работает через сетевой протокол Redis и доводит повреждение памяти до запуска команды от имени серверного процесса. Для атаки требуется доступ к экземпляру Redis и право выполнять несколько опасных команд, включая RESTORE. Проблема находилась в обработке сериализованных данных TDigest. TDigest — структура для приблизительного расчёта процентилей и распределения значений.

Во время восстановления объекта модуль выделял массивы на основании одного параметра, а затем загружал из входных данных другое значение вместимости. Последующие проверки могли использовать число, контролируемое отправителем, вместо настоящего размера выделенной памяти.

Подготовленный объект создавал запись за границами массива в куче. В опубликованной демонстрации эта ошибка превращалась в последовательность примитивов для получения адресов памяти, изменения указателя и вызова системной функции. Итогом становилось выполнение команды с правами пользователя Redis.

Авторы PoC утверждают, что сервер оставался работоспособным, а необходимые адреса определялись во время выполнения без заранее заданных смещений. Независимой проверки переносимости эксплойта на произвольные сборки и рабочие серверы пока нет.

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

Доступ всё же может появиться после утечки пароля, SSRF в соседнем веб-приложении, ошибки сетевых правил или компрометации внутреннего сервиса. Широкие списки контроля доступа часто разрешают приложению команды, которые ему фактически не нужны.

Официальный бюллетень RedisBloom также относит похожие ошибки RESTORE к постаутентификационным: атакующему нужны загруженный модуль RedisBloom, действующая учётная запись и разрешение на RESTORE. Redis оценила этот класс проблем в 7,7 балла из 10.

Публично доступный Redis без пароля фактически снимает условие авторизации. Администратору недостаточно установить пароль: порт нужно закрыть межсетевым экраном, а права приложений — ограничить необходимым минимумом.

Redis ещё 5 мая опубликовала бюллетень о некорректной обработке подготовленных данных RESTORE в RedisBloom. В нём указывалось, что проблема затрагивает все версии модуля и способна привести к выполнению кода. Авторами первоначального отчёта названы Джозеф Сурин и Дэниел Файрер.

Redis 8.8.0 уже содержала исправление CVE-2026-25589 — ошибки RESTORE в вероятностных структурах данных. Версия 8.8.1, выпущенная 23 июля, закрыла дополнительный набор проверок: подготовленные объекты RedisBloom и TDigest могли вызвать запись за границы памяти.

Патч от 23 июля проверяет соответствие загруженной вместимости реально выделенным массивам, контролирует счётчики узлов и отклоняет повреждённые данные. Но Kimi K3, как утверждает исследователь, независимо обнаружила пригодную для эксплуатации ошибку в уже известной разработчикам области обработки RESTORE и автоматически довела её до рабочей RCE-цепочки.

Исправление вошло в Redis 8.8.1. В примечаниях к выпуску прямо указано, что подготовленные объекты RedisBloom и TDigest могли вызвать запись за границы памяти и потенциальное выполнение кода.

Обновления также вышли для нескольких предыдущих веток:

• Redis 8.6.5;

• Redis 8.4.5;

• Redis 8.2.8.

Эти версии закрывают ошибки RedisBloom и TDigest, а также отдельное освобождение уже освобождённой памяти при восстановлении группы потребителей потоков.

Redis 8.8.1 исправляет только проблему модуля, поскольку отдельная ошибка потоков уже была устранена в ветке 8.8.

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

Основной временной мерой до обновления остаётся запрет RESTORE для недоверенных пользователей. Официальный бюллетень RedisBloom рекомендует убрать это разрешение через ACL.

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

Практические меры защиты:

• закрыть Redis от публичного интернета;

• разрешить подключение только доверенным приложениям;

• включить обязательную аутентификацию;

• удалить у сервисных учётных записей права на RESTORE, CONFIG, EVAL и управление модулями, если они не нужны;

• проверить журналы на необычные вызовы RESTORE и создание TDigest-объектов;

• установить последнюю исправленную версию своей ветки.

Готовый PoC показывает, что модель с агентной оболочкой способна участвовать в полном цикле исследования: читать большую кодовую базу, создавать тесты, запускать сборку, анализировать сбои и дорабатывать цепочку эксплуатации.

Документация Kimi Code подтверждает поддержку изолированных подагентов, выполнения команд и распределения независимых задач. Каждый подагент использует отдельный контекст и расходует собственные токены.

Британский Институт безопасности ИИ и американский Центр стандартов и инноваций в области ИИ 23 июля опубликовали предварительную оценку Kimi K3.

На ExploitBench модель получила общий результат 32%, но не дошла до произвольного выполнения кода ни в одной из 41 задачи. Наиболее сильные закрытые модели достигали этой стадии в среднем в 20 задачах.

В имитированной корпоративной сети Kimi K3 в среднем прошла 17 из 32 этапов атаки и полностью завершила сценарий в одной из десяти попыток. Ведущие модели проходили в среднем 28,5 этапа.

Вопросы и ответы

Kimi K3 действительно собрала Redis RCE?

Опубликованный репозиторий содержит рабочую демонстрацию постаутентификационного выполнения кода через обработчик TDigest в RedisBloom. Автор утверждает, что цепочку построил автономный агент.

Доказано ли, что работа заняла 27 минут?

Нет. Это заявление автора эксперимента. Полный журнал агентного сеанса и независимое воспроизведение хронометража не опубликованы.

Kimi первой нашла уязвимость?

Публичная переписка в репозитории указывает, что первоначальный отчёт поступил Redis 29 декабря 2025 года. Отчёт автора PoC был закрыт как дубликат.

Это zero-day?

Во время демонстрации для конкретной TDigest-цепочки не было публичного исправления. Разработчики при этом уже знали о проблеме или о близкой ошибке в той же области. Называть её новым zero-day, открытым Kimi, некорректно.

Требуется ли пароль от Redis?

Нужен доступ к серверу и разрешение выполнять необходимые команды. На экземпляре без аутентификации это условие выполняется автоматически.

Какие версии Redis содержат исправление?

Исправления вышли в Redis 8.8.1, 8.6.5, 8.4.5 и 8.2.8.

Kimi нашла 19 нулевых дней?

Так утверждает автор, но отдельных подтверждённых отчётов нет. Среди результатов могут быть дубликаты и разные проявления одной ошибки.