В Redis обнаружен комплекс проблем безопасности, затрагивающих загрузку RDB-файлов, проверку TLS-сертификатов и механизм контроля доступа ACL. Вредоносный файл данных или специально сформированный запрос могут привести к выполнению произвольного кода, обходу аутентификации клиента и доступу к ключам, которые пользователю не разрешено читать или изменять. Под ударом находятся все поддерживаемые ветки Redis начиная с версии 8.2.
Детали уязвимостей
Наиболее серьёзная уязвимость получила идентификатор CVE-2026-62356. Она связана с неверным расчётом размера буфера при загрузке структуры CMSketch из RDB-файла. Из-за ошибки возникает запись за пределами выделенной области кучи. Это классический вектор для повреждения памяти, который во многих случаях позволяет злоумышленнику выполнить код на сервере. Для эксплуатации достаточно, чтобы Redis обработал специально созданный RDB-файл, например переданный через команду восстановления или при репликации.
Вторая проблема того же класса касается обработки поля SLOT_INFO при загрузке RDB. Некорректное значение идентификатора слота вызывает повреждение памяти, которое также может закончиться удалённым выполнением кода. Разработчики прямо отмечают возможность RCE, поэтому эту уязвимость следует рассматривать как критическую для сред, где Redis принимает данные из внешних источников.
Кроме того, исправлены несколько ошибок, приводящих к выходу за границы массива и использованию памяти после освобождения (use-after-free). Например, некорректный путь очистки кучи в модуле TopK, а также проблемы в работе с векторными множествами: отсутствие проверки уровня узла при загрузке, повреждение графа HNSW при параллельном выполнении поисковых потоков и ошибочная интерпретация отрицательного результата поиска как огромного беззнакового числа. Каждая из этих ошибок может вызвать отказ в обслуживании или неопределённое поведение, а в ряде случаев - привести к несанкционированному доступу к данным.
Отдельного внимания заслуживает уязвимость в проверке клиентских сертификатов TLS. Если в поле Common Name сертификата содержится встроенный нулевой байт, Redis обрезает строку до этого байта и сверяет с ACL-правилами только её начало. В результате клиент с сертификатом, содержащим NUL, может пройти аутентификацию под другим, в том числе привилегированным, пользователем. Это позволяет обойти ограничения прав и получить доступ к операциям, которые должны быть запрещены. Проблема особенно актуальна для сред, использующих взаимную TLS-аутентификацию на основе сертификатов.
Ещё одна группа исправлений касается обхода ACL. В командах SORT, GEORADIUS, GEORADIUSBYMEMBER, XREAD и XREADGROUP проверка прав доступа к ключам выполнялась некорректно. Для геопространственных команд действовало правило "последнее вхождение ключа выигрывает", но ACL проверял только первое. Поэтому команда вида GEORADIUS ... STORE разрешённый_ключ STORE запрещённый_ключ проходила проверку, хотя запись реально выполнялась во второй ключ. В SORT аналогичная проблема возникала из-за того, что парсер не пропускал аргумент после STORE, и значение, похожее на опцию (например, BY или GET), сбивало разбор. Команды XREAD и XREADGROUP могли перепутать позицию ключевого слова STREAMS, если имя группы или потребителя совпадало с этим словом или опции сдвигали реальный токен. В результате проверялся не тот аргумент, и чтение попадало в запрещённый поток.
Разработчики внесли изменения в логику разрешения ключей для ACL. Теперь для этих команд используется собственные функции получения ключей, которые корректно обрабатывают повторяющиеся опции и находят реальные ключи с учётом флагов доступа. Для команд XREAD и XREADGROUP функции вызова пропускают опции COUNT, MAXCOUNT, MAXSIZE, CLAIM и GROUP, чтобы добраться до настоящего токена STREAMS. Такое поведение является намеренным изменением, хотя и может сказаться на некоторых сценариях, которые раньше ошибочно считались допустимыми.
Наконец, исправлена уязвимость в обработчике заблокированных клиентов. При повторной обработке команд, ожидающих на одном ключе, один клиент мог быть удалён из-за политики вытеснения памяти, а список продолжал хранить ссылку на него. Это приводило к использованию памяти после освобождения. Теперь обход списка выполняется безопасно, с повторным получением актуальной структуры на каждой итерации.
Версии с исправлениями выпущены для всех поддерживаемых веток: 8.10.1, 8.8.2, 8.6.6, 8.4.6 и 8.2.9. Администраторам Redis рекомендуется как можно скорее обновить серверы до актуальных версий. Особое внимание стоит уделить системам, которые принимают RDB-файлы из ненадёжных источников, используют TLS для клиентских подключений или полагаются на ACL для разграничения доступа в многопользовательской среде. Для тех, кто не может немедленно выполнить обновление, стоит ограничить сетевой доступ к экземплярам Redis и временно отключить функции, связанные с загрузкой внешних файлов данных, если это допустимо.
Ни одна из описанных уязвимостей пока не имеет публичных сообщений об активной эксплуатации в реальных атаках. Тем не менее, совокупность проблем, включая возможность удалённого выполнения кода и обхода аутентификации, делает обновление приоритетным. Redis остаётся одной из самых распространённых систем хранения данных, и ошибки в его механизмах загрузки и авторизации затрагивают тысячи организаций. Регулярное обновление до поддерживаемых версий - минимально необходимая мера для снижения риска.
Ссылки
- https://github.com/redis/redis/releases/tag/8.10.1
- https://github.com/redis/redis/releases/tag/8.8.2
- https://github.com/redis/redis/releases/tag/8.6.6
- https://github.com/redis/redis/releases/tag/8.4.6
- https://github.com/redis/redis/releases/tag/8.2.9
