Критическая уязвимость в Redis позволяет выполнить произвольный код — патчи уже доступны

5 мая Redis выпустил исправления для пяти уязвимостей класса RCE, наиболее серьёзная из которых — CVE-2026-23479 — получила оценку CVSS 8.8 по версии NVD (v3.1). Это ошибка типа use-after-free (CWE-416), присутствовавшая во всех стабильных ветках Redis начиная с версии 7.2.0 — более двух лет. Публичный эксплойт уже доступен, хотя случаев эксплуатации в реальных атаках пока не зафиксировано. Всем администраторам Redis-инстансов необходимо обновиться до версий 7.2.14, 7.4.9, 8.2.6, 8.4.3 или 8.6.3, а при невозможности немедленного обновления — ограничить ACL-привилегии и сетевой доступ к серверу.

Техническая суть уязвимости

Уязвимость находится в функции unblockClientOnKey() в файле src/blocked.c. Эта функция вызывается при пробуждении заблокированной команды по событию ключа. Она передаёт поставленную в очередь команду через processCommandAndResetClient(), а затем продолжает использовать тот же указатель на клиентскую структуру. Проблема в том, что processCommandAndResetClient() может освободить клиент как побочный эффект — об этом прямо сказано в комментарии к заголовку функции. Вызывающий код игнорирует возвращаемое значение и обращается к уже освобождённой памяти.

По данным исследователей, баг возник в результате взаимодействия двух коммитов. Рефакторинг в январе 2023 года (PR #11012) добавил непроверяемый вызов. Изменение в марте 2023 года (PR #11568) добавило дополнительный доступ к клиентской структуре после этого вызова. Ни один из коммитов по отдельности не создавал уязвимость — опасной стала именно их комбинация, попавшая в общий доступ с версией 7.2.0.

Redis оценивает уязвимость по CVSS 4.0 на уровне 7.7, что ниже оценки NVD. Расхождение объясняется различиями в методологиях оценки версий 3.1 и 4.0, а не спором о серьёзности.

Опубликованная цепочка эксплуатации

Полное техническое описание эксплойта уже опубликовано. Как сообщается, цепочка атаки состоит из трёх этапов:

• Утечка адреса кучи. Однострочный Lua-скрипт (EVAL "return tostring(redis.call)" 0) возвращает указатель на кучу, необходимый для дальнейших вычислений.
• Подмена клиентской структуры. Атакующий манипулирует лимитами памяти клиента, блокирует «раздутый» клиент на потоке (stream), затем сбрасывает лимиты и пробуждает его. Redis освобождает заблокированного клиента в середине обработки, а конвейерная команда SET немедленно занимает освободившийся слот поддельной клиентской структурой.
• Перезапись указателя функции. Штатный механизм учёта памяти в updateClientMemoryUsage() выполняет выход за границы массива с декрементом, используя контролируемые атакующим поля. Цель — таблица глобальных смещений (GOT): перенаправление strcasecmp() на system(). Следующая команда, которую Redis разбирает, выполняется как shell-команда.

Официальный Docker-образ Redis, по данным исследователей, поставляется с частичным RELRO, оставляя GOT доступной для записи во время выполнения. ASLR и PIE не помогают, поскольку запись выполняется относительно глобальной переменной с фиксированным смещением на этапе сборки.

Требования к эксплуатации и масштаб угрозы

Полная цепочка эксплойта требует аутентифицированной сессии с привилегиями CONFIG SET, EVAL, потоковых команд (XREAD/XADD) и базовых SET/GET. В терминах ACL Redis это категории @admin, @scripting, @stream, @read и @write. Пользователь по умолчанию обладает всеми этими привилегиями.

Уязвимость обнаружила команда Team Xint Code. Компания Theori описывает Xint Code как автономный инструмент безопасности на основе ИИ, предназначенный для поиска ошибок в крупных кодовых базах. Это примечательный случай: два коммита создали уязвимость, она прошла множество раундов ревью кода за два года, и в итоге её нашёл не человек, а автоматизированный инструмент в рамках хакерского соревнования.

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

Практические рекомендации

Приоритет — немедленное обновление. Установите исправленные версии для вашей серии:

• Redis 7.2 → 7.2.14
• Redis 7.4 → 7.4.9
• Redis 8.2 → 8.2.6
• Redis 8.4 → 8.4.3
• Redis 8.6 → 8.6.3

Redis Cloud, по заявлению вендора, уже обновлён. Управляемые сервисы других провайдеров обновляются по собственным графикам — уточните статус у вашего провайдера.

Если немедленное обновление невозможно:

• Исключите прямой доступ к Redis из интернета, разместите его за TLS.
• Разделите ACL-привилегии: ни одна роль не должна одновременно обладать @admin, CONFIG и @scripting.
• Запретите категорию @scripting, если Lua-скрипты не используются — это блокирует первый этап цепочки (утечку адреса кучи).
• Запрет CONFIG ломает конкретную опубликованную цепочку, но не устраняет базовую ошибку use-after-free.
• Ротируйте все общие учётные данные Redis.

В первую очередь обратите внимание на инстансы, доступные из интернета, на общие учётные записи приложений и на любые роли, совмещающие доступ к CONFIG, скриптам и потокам.

CVE-2026-23479 — одна из пяти уязвимостей класса RCE, раскрытых в одном пакете обновлений Redis, и вторая за последнее время ошибка use-after-free в Redis, связанная с Lua-скриптингом. Наличие публичного PoC при массовом развёртывании Redis делает окно для безопасного обновления крайне узким. Обновите затронутые инстансы до исправленных минорных версий сейчас, а не после появления первых отчётов об атаках.