Даже после установки официальных исправлений старые уязвимости в Redis не всегда оказываются полностью закрытыми. Опубликованный набор демонстрационных эксплойтов демонстрирует удалённое выполнение команд на версиях 6.2.22, 7.4.9, 8.6.4, 8.8.0 и 8.8.1. Часть вредоносного кода обходит ранее выпущенные исправления для CVE-2026-25243 и CVE-2026-25589 - обе уязвимости имеют оценку 8.8 по шкале CVSS 3.1, что соответствует высокому уровню угрозы.
Детали уязвимостей
Представленные эксплойты используют три различных вектора. Первый из них - повторное освобождение участка памяти (double free) при обработке общих отрицательных подтверждений в группах потребителей Redis Streams. Этот сбой позволяет нарушить структуру памяти процесса и добиться выполнения произвольной команды на сервере. Уязвимость проявляется в версиях 6.2.22, 7.4.9 и 8.6.4. Опубликованный эксплойт стабильно работает, несмотря на то, что CVE-2026-25243 уже была исправлена в Redis 8.8.0 (исправление внесено через pull request #15081). Однако, как показали авторы, патч оказался неполным, и обход возможен в версиях, где исправление было применено частично или не затрагивает все сценарии.
Второй вектор затрагивает Redis 8.8.0 и использует переполнение кучи в структуре TDigest, входящей в состав встроенного модуля RedisBloom. Эксплойт манипулирует данными в памяти, вызывая запись за пределами выделенного буфера, что приводит к выполнению кода. Для ветки 8.8.0 и 8.8.1 также разработан третий вариант атаки - через структуру TopK того же модуля RedisBloom. Он обходит неполное исправление CVE-2026-25589: после обнуления части указателей функция удаления продолжала обращаться к элементам за пределами выделенного участка памяти. Это означает, что даже после выхода патча уязвимость остаётся актуальной для RedisBloom версий 8.8.0 и 8.8.2.
Для запуска любого из эксплойтов атакующему требуется возможность отправлять на сервер команды EVAL, RESTORE и XGROUP. Для версий 8.8.0 и 8.8.1 также необходимо наличие встроенного модуля RedisBloom (он присутствует в официальных образах по умолчанию). Демонстрационные сценарии зависят от расположения объектов в памяти, поэтому авторы тестировали их на свежих официальных контейнерах без посторонних подключений и команд. На момент проверок эксплойты стабильно выполняли заданные команды на всех поддерживаемых версиях: 10 из 10 для 6.2.22, 5 из 5 для 7.4.9, 25 из 25 для 8.6.4 и 5 из 5 для 8.8.0.
Авторы описывают код как недеструктивный, однако после его запуска в базе данных остаются служебные ключи, а также повреждённые структуры (особенно в случае с TDigest). Использование неверных смещений для неофициальной сборки может аварийно завершить процесс Redis. Набор опубликован исключительно для санкционированного тестирования. Разработчики рекомендуют запускать демонстрации на свежих изолированных экземплярах, отдельно рассчитывать смещения для неофициальных сборок и не сохранять состояние Redis 8.8.0 после эксплуатации ошибки TDigest.
Пользователям Redis следует оценить риски: если экземпляры доступны недоверенным пользователям, уязвимости позволяют получить полный контроль над сервером. В качестве временных мер можно ограничить доступ к командам EVAL, RESTORE и XGROUP, а также отключить модуль RedisBloom, если он не требуется. Однако наиболее надёжный способ - обновление до версий, в которых данные проблемы устранены полностью. На момент публикации информация о полном исправлении для всех затронутых веток отсутствует, поэтому необходимо отслеживать официальные бюллетени Redis.
Эти находки в очередной раз привлекают внимание к сложности полного закрытия уязвимостей, связанных с управлением памятью, особенно в системах с активным многопоточным доступом. Даже тщательное патчирование не всегда гарантирует отсутствие обходных путей, что требует от разработчиков более глубокого аудита и от пользователей - своевременного применения обновлений по мере их выхода.
Ссылки
