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

Kimi K3 агенты нашли zero-day в Redis и создали RCE эксплойт

Исследователи из группы Bera Buddies сообщили, что ИИ-агенты под названием Kimi K3 обнаружили 19 zero-day уязвимостей в Redis и разработали рабочий эксплойт для удаленного выполнения кода (RCE). Уязвимости затрагивают версии Redis 6.2.22, 7.4.9, 8.6.4 и 8.8.0. 23 июля компания Redis выпустила исправления для соответствующих веток.

Два пути эксплуатации

Оба выявленных вектора атаки требуют использования команды RESTORE. Первый путь связан с механизмом Streams и ошибкой совместного владения (shared-ownership bug). Поврежденный RDB-объект может заставить два потребителя указывать на одну и ту же запись ожидающего сообщения (streamNACK). При удалении первого потребителя объект освобождается, и второй потребитель получает висячий указатель. Удаление второго приводит к двойному освобождению памяти.

Второй путь лежит в модуле RedisBloom, где функция загрузки TDigest не проверяет соответствие выделенной памяти и переданного значения capacity. Небольшое реальное выделение в сочетании с завышенными метаданными приводит к выходу за границы буфера (out-of-bounds write).

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

Детали эксплойта

Эксплойт для Redis 8.8.0 (через RedisBloom) превращает внеграничную запись в примитивы чтения и записи, утекает адреса Redis и libc, после чего манипулирует хеш-функцией базы данных так, что специально сформированная команда GET вызывает system(). Эксплойт для Redis 6.2.22 (через Streams) использует двойное освобождение для получения произвольного доступа к памяти с последующим вызовом system().

Оба Proof-of-Concept были опубликованы в открытом доступе. Redis рекомендует немедленно обновить серверы до исправленных версий или, как временную меру, отозвать привилегии RESTORE у учетных записей, которые не нуждаются в этой команде, а также заблокировать недоверенный сетевой доступ.

  • Redis 6.2.23, 7.2.15, 7.4.10 — исправляют Streams shared-NACK use-after-free
  • Redis 8.2.8, 8.4.5, 8.6.5 — исправляют Streams и RedisBloom/TDigest out-of-bounds writes
  • Redis 8.8.1 — исправляет RedisBloom и TDigest загрузчики; защита Streams уже присутствовала в 8.8.0

Примечательно, что версии Redis 6.2.22 и 7.4.9 были рекомендованы в мае как обновления безопасности, но они не включали защиту от shared-NACK ошибки. Таким образом, пользователям этих веток требуется дополнительное обновление.

Никаких CVE и атак в дикой природе

На момент публикации 24 июля 2026 года ни один из новых багов не получил отдельного номера CVE или оценки CVSS в официальных заметках Redis. База данных NVD по-прежнему содержит только майские записи CVE-2026-25243 и CVE-2026-25589. Каталог CISA Known Exploited Vulnerabilities также не содержит записей об этих проблемах. Redis отмечает, что проблема Streams может относиться к «семейству неполных исправлений» CVE-2026-25589, но это не подтверждено.

Само обнаружение стало возможным благодаря ИИ-агентам Kimi K3. По словам Чаофана Шоу (Chaofan Shou), агенты нашли 19 zero-day уязвимостей Redis примерно за 90 минут, а отдельный запуск создал эксплойт для Redis 8.8.0 за 27 минут. Впрочем, эти данные остаются самоотчетными — Redis подтверждает наличие и исправление дефектов, но не валидирует количество уязвимостей или степень автономности ИИ.

Читайте также: Лучшие бесплатные антивирусы для защиты от RCE-атак

Источник: The Hacker News

Похожие записи