26 октября 2026 года разработчики Redis выпустили версию 8.10.3 с исправлением переполнения буфера в оперативной памяти при передаче сообщений PUBLISH и SPUBLISH размером более 4 ГБ между узлами кластера. Проблема относится к механизму межузловой связи Redis Cluster, а аналогичные патчи одновременно появились для нескольких других веток продукта.
Redis Cluster мог некорректно обрабатывать сообщения объёмом более 4 ГБ
Разработчики описали ошибку как heap buffer overflow — переполнение буфера в куче. Так называют ситуацию, когда программа при обработке данных выходит за пределы выделенного ей участка оперативной памяти. Это может привести к повреждению данных в памяти или сбою процесса, хотя конкретные последствия зависят от устройства ошибки.
В Redis 8.10.3 исправлен случай, возникающий при распространении сообщений PUBLISH или SPUBLISH размером свыше 4 ГБ через cluster bus. Этот внутренний канал нужен узлам Redis Cluster для обмена служебной информацией и передачи сообщений. Разработчики пометили выпуск категорией SECURITY, указав на характер исправления.
Условие с размером сообщения заслуживает отдельного внимания. Согласно документации Redis, максимальный размер значения типа String по умолчанию составляет 512 МБ. Поэтому передача сообщения объёмом более 4 ГБ существенно отличается от типичного сценария публикации коротких уведомлений. В примечаниях к релизу не описано, при каких настройках или дополнительных условиях удаётся достичь такого размера.
PUBLISH и SPUBLISH используют разные маршруты внутри кластера
Redis часто применяют как систему обмена событиями между приложениями. Механизм Pub/Sub работает просто: один участник публикует сообщение в канал, а подключённые подписчики получают его, пока остаются в сети. Например, таким способом можно сообщить нескольким экземплярам веб-приложения об изменении данных.
В Redis Cluster у двух упомянутых команд разные правила распространения сообщений:
PUBLISHотносится к обычному Pub/Sub. В кластерном режиме сообщение передаётся всем узлам кластера, чтобы подписчики могли получать его независимо от того, к какому узлу подключены.SPUBLISHотносится к sharded Pub/Sub, появившемуся в Redis 7.0. Сообщение пересылается только внутри шарда, которому принадлежит соответствующий канал. Это уменьшает объём межузлового трафика по сравнению с общей рассылкой.
Обе схемы используют межузловое взаимодействие. Именно этот участок обработки упомянут в описании исправления Redis 8.10.3. Различие в маршрутах помогает понять, почему ошибка, связанная с Pub/Sub, важна именно при работе нескольких узлов в кластере.
Cluster bus — отдельный сетевой канал Redis со своей моделью безопасности
У Redis Cluster обычно есть два TCP-порта. Один обслуживает клиентские команды: часто это 6379. Другой предназначен для cluster bus: по умолчанию его номер на 10 000 больше клиентского, то есть 16379 при порте 6379. Через него узлы обмениваются информацией о состоянии кластера, обнаруживают сбои и согласуют переключение ролей.
С этим каналом уже было связано предыдущее обновление безопасности. В Redis 8.10.2, опубликованном 17 сентября 2026 года, разработчики добавили предупреждение о работе cluster bus без аутентификации и параметр cluster-bus-port-protected-mode. При значении yes он требует использования аутентифицированного соединения tls-cluster для запуска узла; по умолчанию параметр имеет значение no.
Сентябрьское исправление касалось защиты доступа к межузловому каналу. В октябрьском выпуске устранили ошибку обработки очень больших сообщений, проходящих по этому каналу. Это два разных аспекта безопасности Redis Cluster.
Исправление получили семь поддерживаемых веток Redis
26 октября разработчики опубликовали патчи сразу для нескольких версий Redis Open Source. В официальном списке выпусков указаны 8.10.3, 8.8.4, 8.6.8, 8.4.8, 8.2.11, 7.4.12 и 7.2.17. Во всех семи описаниях повторяется одно и то же исправление переполнения буфера при передаче сообщений PUBLISH или SPUBLISH свыше 4 ГБ через cluster bus.
Для ветки 8.10 предыдущей версией была 8.10.2. В заметке о выпуске 8.10.3 разработчики перечислили только исправление безопасности: о новых командах, изменениях API или дополнительных функциях там не сообщается.
Для проектов, работающих с Redis в режиме отдельного сервера без Redis Cluster, описанный путь передачи данных между узлами отсутствует. В кластерных установках значение имеют и используемый механизм Pub/Sub, и условия обработки сообщений очень большого размера. Простое наличие в приложении команды PUBLISH ещё не означает, что оно воспроизводит описанный сценарий.
Подробности эксплуатации ошибки пока ограничены описанием исправления
На момент публикации в официальных примечаниях к Redis 8.10.3 указан тип ошибки и условие её возникновения, но не приведены идентификатор CVE, оценка CVSS, пример эксплуатации или подтверждённые последствия конкретной атаки. Поэтому по одному описанию нельзя утверждать, что ошибка позволяла удалённо выполнять код либо затрагивала обычные сообщения малого размера.
Известная граница проблемы достаточно конкретна: передача сообщения более 4 ГБ через cluster bus в кластерном режиме. Выпуск 8.10.3 устраняет этот случай в текущей ветке Redis 8.10, а синхронные патчи охватывают ещё шесть веток. Более подробная техническая оценка риска зависит от информации, которую разработчики пока не опубликовали.
