> diffnotes · 25 Jul 2026 · 8 мин

Иди проверь версию Redis: майский патч не спасает, PoC уже в открытом гите. А дыры нашёл рой агентов на Kimi K3

23 июля Redis выпустил семь релизов безопасности за один день. Поводом стали опубликованные PoC с рабочей аутентифицированной RCE против стоковых сборок 6.2.22, 7.4.9, 8.6.4 и 8.8.0 — то есть против официальных докер-образов, без экзотических конфигов. Нашёл эти дыры не человек, а рой агентов на открытой модели Kimi K3.

TL;DR: Проверь точную версию своего Redis: 6.2.22 и 7.4.9 — это те самые «безопасные» майские апдейты, и оба пробиты. Патчи вышли 23 июля (6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5, 8.8.1). Обе цепочки идут через RESTORE — если апгрейд прямо сейчас невозможен, отзови эту команду у прикладных пользователей. CVE на новые баги нет, поэтому твой сканер уязвимостей молчит.

Какие версии Redis уязвимы и куда обновляться

Уязвимы стоковые 6.2.22, 7.4.9, 8.6.4 и 8.8.0: именно эти сборки были целями опубликованных PoC. Патчи: 6.2.23, 7.2.15 и 7.4.10 закрывают use-after-free в Streams; 8.2.8, 8.4.5 и 8.6.5 закрывают и Streams, и out-of-bounds запись в RedisBloom/TDigest; 8.8.1 чинит загрузчики RedisBloom и TDigest, а защита Streams в 8.8.0 уже была.

Самая неприятная деталь: 6.2.22 и 7.4.9 — это ровно те релизы, на которые Redis просил обновиться в мае. В них не оказалось проверки владения shared-NACK. То есть команды, которые честно накатили майский патч, сейчас всё так же уязвимы. Проверять надо не «мы недавно обновлялись», а конкретный номер в конкретной ветке:

redis-cli INFO server | grep redis_version
# или, если гоняешь в контейнере
docker exec <container> redis-server --version

Если апгрейд сегодня не выйдет, обе опубликованные цепочки отрезаются одним движением: отзывом RESTORE у тех аккаунтов, которым он не нужен позарез:

redis-cli ACL SETUSER appuser -restore
# и заодно закрыть сеть от недоверенных клиентов

Дополнительно: цепочки в Streams требуют ещё EVAL и XGROUP, а цепочка для 8.8.0 — EVAL и подключённый модуль RedisBloom. Но именно RESTORE — общий знаменатель всех четырёх.

Как устроены обе цепочки

Первый путь — двойное освобождение в Streams. Битый RDB-объект заставляет двух консьюмеров указывать на одну и ту же запись pending-entry (внутри это streamNACK). Удаляешь первого консьюмера — объект освобождается, у второго остаётся висячий указатель. Удаляешь второго — один и тот же кусок памяти освобождается дважды. Опубликованный скрипт превращает эту порчу памяти в произвольный доступ к памяти и в итоге вызывает system().

Второй путь — out-of-bounds запись в загрузчике TDigest из RedisBloom. Загрузчик выделяет память исходя из одного сериализованного значения, но доверяет отдельному полю ёмкости, которое контролирует атакующий. Дальше по классике: примитивы чтения и записи, утечка адресов Redis и libc, system().

Отдельного упоминания стоит история с релиз-нотами 8.6.4. В них указан PR #15081, который добавляет проверку дублирующегося владения. The Hacker News сверил исходники тега 8.6.4 — этой проверки в них нет. Появляется она только в 8.6.5. Мораль простая: релиз-ноты — это заявление о намерениях, а не доказательство. Если баг критичный, смотри src/rdb.c в теге, который ты реально выкатываешь.

Почему сканер уязвимостей ничего не покажет

На новые баги не заведено ни CVE, ни CVSS. Redis не указал их в июльских релиз-нотах. Значит, автоматические проверки, которые сверяются с NVD, вернут «чисто».

По состоянию на 24 июля в NVD висели только майские записи CVE-2026-25243 и CVE-2026-25589, а в каталоге известных эксплуатируемых уязвимостей CISA не было ни одной. Репозиторий с PoC называет проблему в Streams частью «семейства неполного фикса CVE-2026-25589», но сам Redis маппит этот CVE на порчу памяти в RedisBloom при RESTORE, а не на shared-NACK. Формально это разные баги, и нового идентификатора у них пока нет.

Хорошая новость: ни июльские релиз-ноты Redis, ни просмотренные публичные репозитории с PoC не сообщали об эксплуатации в дикой природе на 24 июля. Плохая: PoC лежат в открытом доступе — berabuddies/redis-poc и Lyutoon/redis-RCE-poc.

Что здесь важнее самих дыр

Kimi K3 — открытая модель Moonshot на 2,8 трлн параметров с окном в 1M токенов, вышедшая 16 июля и стоящая $3/$15 за миллион токенов. Через неделю после релиза рой агентов на ней выдаёт рабочие RCE-цепочки против одной из самых развёрнутых баз данных в мире.

Исследователь Chaofan Shou написал в X, что агенты на Kimi K3 нашли 19 zero-day в Redis примерно за 90 минут, а рабочий эксплойт под 8.8.0 получился за 27 минут в отдельном прогоне. Эти цифры — самоотчёт. Публичная запись Redis подтверждает сами баги и фиксы, но не подтверждает ни счёт находок, ни то, насколько самостоятельно работали агенты. Относиться к «19 за 90 минут» стоит как к маркетинговому числу, пока никто не воспроизвёл прогон.

А теперь ирония дня. Ровно 24 июля вышла предварительная совместная оценка британского AISI и американского CAISI: Kimi K3 набрала 32,2% на ExploitBench против 76,2% в среднем у топовых американских frontier-моделей и не смогла добиться выполнения произвольного кода ни на одной из 41 протестированной уязвимости. Формулировка оценщиков — «работает значительно ниже самых свежих frontier-моделей с кибер-способностями». Модель обошла китайскую GLM-5.2 (24,4%), и на этом всё.

То есть в один и тот же день государственные оценщики пишут «слабая на эксплуатации», а независимые исследователи публикуют собранные ею рабочие эксплойты под Redis. Противоречия здесь меньше, чем кажется: бенчмарк меряет одиночную модель на фиксированном наборе задач, а Bera Buddies гоняли рой агентов с инструментами, фаззингом и множеством попыток. Разница между «модель» и «модель в хорошей обвязке» на этой неделе получила очень наглядную иллюстрацию. Мы про это же писали, когда GPT-5.6 нашла unauth RCE в ядре WordPress за $25 — там был тот же паттерн.

Из той же оценки AISI/CAISI есть отдельная строчка, которую стоит прочитать всем, кто рассматривает K3 для своих задач: защитные механизмы модели не блокировали запросы на наступательные кибероперации во время тестирования.

Подводные камни

«Мы обновились в мае» — не аргумент. 6.2.22 и 7.4.9 были рекомендованными майскими апдейтами и оба пробиты. Проверяй номер версии в ветке, а не факт обновления.
Релиз-ноты соврали. В 8.6.4 указан PR с проверкой, которой в теге нет. Если ты принимаешь решение об апгрейде по чейнджлогу — рискуешь принять его неверно.
CVE нет, значит сканеры молчат. Ни NVD, ни CISA KEV не содержат записей по июльским находкам. Compliance-отчёт покажет зелёный статус на уязвимом сервере.
Требуется аутентификация — но это слабая защита. Атака аутентифицированная, и звучит успокаивающе ровно до момента, когда вспоминаешь, сколько Redis-инстансов живёт с одним общим паролем на все приложения или вообще без него во внутренней сети.
RedisBloom тянет свой набор рисков. Цепочка для 8.8.0 работает через штатно поставляемый модуль. Если модули не нужны — не грузи их, это лишняя поверхность атаки в комплекте.
Цифры про агентов самозаявленные. 19 багов за 90 минут и эксплойт за 27 минут взяты из твитов исследователя, независимого воспроизведения нет.

Альтернативы, если хочется проверить себя такими же методами

Strix — открытый AI-пентестер, о котором мы уже писали: рой агентов гоняет твой код и приносит рабочий эксплойт, а не абстрактное предупреждение. Ближайший по духу инструмент к тому, чем работали в Redis.
Классический фаззинг через OSS-Fuzz — дешевле, воспроизводимо, находит ровно тот класс багов памяти, который здесь и всплыл. Медленнее, но результат не надо перепроверять за агентом.
Отдельная frontier-модель с CVP-доступом — Anthropic и другие пускают в программы проверки для security-работы, где не режут кибер-задачи. Формальностей больше, зато и качество эксплуатации выше, чем у открытых моделей.

Вердикт

Обновляйся сегодня, если у тебя 6.2.22, 7.4.9, 8.6.4 или 8.8.0. Это не теоретический риск, PoC лежат в открытом гите. Если апгрейд упирается в окно обслуживания, отзови RESTORE у прикладных пользователей прямо сейчас, это отрезает обе цепочки и делается одной командой. И перестань полагаться на сканер: до появления CVE он будет показывать зелёный статус на пробитом сервере.

Как проверить себя за пять минут

Сними точную версию: redis-cli INFO server | grep redis_version. Сравни с патчами 23 июля: 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5, 8.8.1.
Посмотри, кому доступен RESTORE: redis-cli ACL LIST. Всё, что не про восстановление бэкапов, — кандидат на отзыв.
Проверь, подключён ли RedisBloom, если сидишь на 8.8.x: redis-cli MODULE LIST. Не нужен — выгружай.
Убедись, что порт не смотрит наружу и что у приложений отдельные ACL-пользователи, а не общий root-пароль.
Полный разбор обеих цепочек — в материале The Hacker News, список релизов — на странице релизов Redis.