26 октября разработчики Valkey выпустили версию 9.1.3 с исправлением безопасности в кластерном обмене сообщениями. Ошибка GHSA-f4q9-j22m-xqq9 позволяет авторизованному клиенту вызвать переполнение буфера при публикации слишком большого сообщения. На Mentoring.digital уточняем условия проблемы и порядок проверки обновления.
Проблема затрагивает кластерный режим
По описанию разработчиков, для атаки нужен авторизованный пользователь, который может публиковать сообщения в канале сервера с включённым cluster mode. Ошибка приводит к аварийному завершению процесса; возможность выполнения произвольного кода также рассматривается как потенциальное последствие.
Серверы без кластерного режима этой уязвимостью не затронуты. Это существенная граница: наличие Valkey само по себе не означает одинаковый риск для любой установки. Исправление проверяет допустимую длину сообщения до выделения памяти и передачи между узлами.
Исправления вышли для нескольких веток
В бюллетене указаны исправленные версии 7.2.15, 8.0.12, 8.1.11, 9.0.7 и 9.1.3, а для предварительной ветки 9.2 указан выпуск 9.2.0-rc2. Выбирать обновление нужно для используемой поддерживаемой ветки; предварительную версию не стоит принимать за обязательный маршрут обновления.
В 9.1.3 также исправлено поведение команд потоков, которые меняют состояние групп потребителей и списка ожидающих сообщений. Раньше такие изменения могли не запускать WATCH и уведомление клиентского отслеживания об изменении данных. Это важно для приложений с оптимистическими транзакциями и клиентским кешированием.
Что проверить администратору
Сначала уточните версию сервера, наличие кластерного режима и права приложений на публикацию. Для управляемого сервиса проверьте сведения поставщика об исправлении. Самостоятельный кластер обновляйте по принятому плану с резервной копией и проверкой совместимости клиентов.
После обновления на тестовых данных проверьте обычную доставку Pub/Sub, работу потребителей потоков и ожидаемую реакцию транзакций на изменение данных. Не воспроизводите опасные переполнения на рабочем сервере. Если нужна помощь с зависимостями приложения от кеша и брокера сообщений, задачу можно разобрать с наставником по серверной разработке.
