Redis 8.8.1 закрывает опасную ошибку RESTORE — повреждённые данные могли привести к выполнению кода

Redis выпустила Redis Open Source 8.8.1 23 июля 2026 года и пометила обновление уровнем SECURITY. Версия усиливает проверку сериализованных объектов RedisBloom и TDigest: специально подготовленные данные для команды RESTORE могли вызвать запись за границы памяти и потенциально дать атакующему выполнение кода в процессе Redis.

Redis 8.8.1
Redis 8.8.1

Redis 8.8.1 посвящён одной уязвимости в механизме RESTORE

В официальных примечаниях к выпуску Redis 8.8 для версии 8.8.1 указано одно изменение — исправление безопасности. Разработчики предупреждают, что специально сформированные данные RESTORE для RedisBloom и TDigest могли спровоцировать запись за пределами выделенного участка памяти с риском удалённого выполнения кода.

Релиз Redis 8.8.1 на GitHub появился 23 июля. Патч не добавляет команды или структуры данных и не меняет обычную работу приложений. Его задача сосредоточена на обработке повреждённых либо намеренно подделанных сериализованных объектов.

Для ветки 8.8 практический ориентир однозначен: версия 8.8.0 предшествует исправлению, а 8.8.1 содержит защитные проверки. Владельцам самостоятельно управляемых серверов Redis 8.8 стоит включить этот патч в ближайшее окно обслуживания.

Команда RESTORE восстанавливает ключ из сериализованного объекта

Команда RESTORE создаёт ключ из двоичного представления значения, которое обычно получают через DUMP. Такой механизм применяют при переносе отдельных ключей, миграции данных, восстановлении резервных копий и работе некоторых служебных инструментов.

Внутри сериализованного объекта находятся сами данные и метаданные, описывающие их структуру. Для вероятностных структур это могут быть размер буфера, количество битов, число внутренних фильтров, ёмкость TDigest и количество его узлов. Загрузчик обязан проверить, что заявленные размеры совпадают с фактическим содержимым.

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

TDigest хранит компактное приближение распределения чисел и помогает оценивать процентили, например задержку p95 или p99, без сохранения и сортировки каждого измерения. RedisBloom объединяет вероятностные структуры, включая Bloom filter и Cuckoo filter. Начиная с Redis 8, эти возможности входят в стандартную поставку Redis Open Source, поэтому проблема касается не отдельного вручную подключённого расширения в типичной установке 8.8.

Redis 8.8.1 проверяет размеры буферов и внутренние счётчики

Связанные с выпуском изменения RedisBloom добавляют проверки перед выделением памяти и копированием данных. Загрузчик сверяет размеры сериализованных буферов Bloom filter и Cuckoo filter, ограничивает допустимые значения метаданных и проверяет внутреннюю целостность структуры.

Для TDigest патч сопоставляет сохранённую ёмкость с реально выделенной памятью и проверяет количество объединённых и необъединённых узлов. Повреждённый объект теперь должен завершить RESTORE ошибкой до небезопасной работы с памятью.

Разработчики добавили отдельные тесты с усечёнными буферами и подменёнными значениями ёмкости. Они воспроизводят повреждённые входные данные и закрепляют ожидаемое поведение: Redis отклоняет некорректный объект.

Доступ к RESTORE определяет реальную поверхность атаки

Уязвимый путь открывается клиенту, способному передать сериализованный объект через RESTORE. В документации Redis эта команда относится к категориям ACL @write, @slow и @dangerous. Учётной записи приложения редко требуется право восстанавливать произвольные двоичные объекты во время обычной работы.

Риск выше в трёх сценариях:

  • Redis доступен из недоверенной сети и защищён слабыми либо отсутствующими учётными данными;
  • сервисная учётная запись получила широкие права, включая RESTORE;
  • внешняя система миграции или восстановления принимает объекты из источника, которому нельзя полностью доверять.

ACL позволяет временно убрать RESTORE у пользователей, которым команда не нужна. Такая мера сокращает доступный путь к уязвимости до завершения обновления. Сам патч 8.8.1 остаётся основным исправлением, поскольку служебным и административным учётным записям команда может требоваться.

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

Перед обновлением достаточно проверить фактическую версию каждого узла, включая реплики и контейнеры. Значение redis_version доступно в секции server команды INFO, а локальный бинарный файл показывает версию через redis-server --version.

СценарийПрактический шаг
Самостоятельный Redis 8.8.0Обновить сервер до 8.8.1 и перезапустить узел по принятой схеме обслуживания
Redis в Docker с закреплённым тегом 8.8.0Получить образ 8.8.1 и пересоздать контейнеры, чтобы новый бинарный файл реально запустился
Кластер или набор primary/replicaПроверить версию на каждом узле и сохранить совместимый порядок поэтапного обновления
RESTORE не используется приложениямиЗакрыть команду через ACL у прикладных пользователей до установки патча
Управляемый сервис RedisПроверить бюллетень провайдера и фактическую версию движка в панели сервиса

Резервная копия и проверка восстановления сохраняют прежнюю ценность, хотя релиз меняет только обработку некорректных объектов. После обновления стоит убедиться, что миграционные процедуры, репликация и загрузка штатных RDB-файлов проходят без ошибок.

Идентификатор CVE для июльского исправления пока не указан

В примечаниях Redis 8.8.1 нет отдельного идентификатора CVE, оценки CVSS и перечня всех затронутых веток. Публикация фиксирует наличие риска удалённого выполнения кода и указывает конкретный патч RedisBloom, но оставляет часть деталей без отдельного бюллетеня.

В мае 2026 года Redis уже раскрывала CVE-2026-25589, связанную с некорректной обработкой сериализованных данных RedisBloom через RESTORE. Июльские release notes не связывают Redis 8.8.1 с этим номером напрямую. До дополнительного пояснения разработчиков корректнее рассматривать выпуск как отдельное усиление защиты в том же чувствительном участке загрузчика.

Redis 8.8.1 получился узким обновлением безопасности с понятным назначением. Серверы 8.8.0, где клиентам доступна команда RESTORE, получают наиболее очевидную причину для быстрого перехода: патч заставляет Redis отвергать противоречивые метаданные до копирования данных и тем самым закрывает путь к повреждению памяти.

При использовании материалов сайта необходимо указывать ссылку на TGLand.ru. Если вы копируете фрагменты текста в интернете, прямая гиперссылка, доступная для индексации поисковыми системами, должна быть размещена в начале материала.

Вам также может понравиться