Пятого мая 2026 года компания Redis опубликовала экстренное предупреждение. Она сообщила о пяти уязвимостях, которые затрагивают как коммерческую версию Redis Software, так и открытые сборки OSS и CE. Самое тревожное: четыре из пяти проблем получили высокую оценку опасности - 7,7 балла по шкале CVSS. Пятая уязвимость оценена как средняя - 6,1 балла. Все они позволяют аутентифицированному злоумышленнику выполнить произвольный код на сервере. Иными словами, если у нападающего уже есть учётные данные для доступа к Redis, он может полностью захватить систему.
Детали уязвимостей
Каждая из уязвимостей имеет свой идентификатор CVE (перечень общеизвестных уязвимостей). Первая - CVE‑2026‑23479 - связана с ошибкой типа "использование после освобождения" (use-after-free) в механизме обработки заблокированных клиентов. Когда такой клиент удаляется во время повторного выполнения команды, происходит сбой в управлении памятью. В результате аутентифицированный пользователь может инициировать удалённый код. Вторая - CVE‑2026‑25243 - затрагивает команду RESTORE, которая восстанавливает данные из сериализованного формата. Специально сформированная полезная нагрузка вызывает некорректный доступ к памяти, что также ведёт к выполнению кода. Третья и четвёртая уязвимости - CVE‑2026‑25588 и CVE‑2026‑25589 - являются разновидностями той же проблемы, но проявляются только при использовании модулей RedisTimeSeries и RedisBloom соответственно. Это популярные расширения для работы с временными рядами и вероятностными структурами данных. Пятая уязвимость - CVE‑2026‑23631 - снова относится к ошибке использования после освобождения, но на этот раз в скриптовом движке Lua. Она актуальна только для реплик, у которых отключена опция replica-read-only.
Поясним суть термина "использование после освобождения" простым языком. Представьте, что программа выделила участок памяти для хранения данных, а затем пометила его как свободный. Если после этого код продолжает обращаться к тому же участку, он рискует обратиться к уже перезаписанной или повреждённой информации. Злоумышленник может специально подстроить ситуацию так, чтобы в этот участок памяти попал вредоносный код. Тогда сервер выполнит его. Именно такая схема лежит в основе трёх из пяти уязвимостей.
Важно отметить: для эксплуатации всех этих проблем злоумышленнику необходимо сначала пройти аутентификацию. То есть он должен знать пароль или иметь другие законные учётные данные. Однако это не делает угрозу менее серьёзной. Во многих компаниях Redis используется как высокопроизводительное хранилище сессий или кэш. Доступ к нему часто имеют внутренние сервисы, а пароли могут быть скомпрометированы в результате фишинга или утечек. Кроме того, некоторые администраторы по невнимательности оставляют базу данных открытой для неавторизованного доступа. В таком случае аутентификация вообще не требуется.
Каковы последствия успешной атаки? Злоумышленник получает возможность выполнять произвольные команды от имени процесса Redis. Он может извлечь все данные, хранящиеся в базе, включая токены сессий, персональную информацию пользователей или ключи шифрования. Более того, имея доступ к серверу, нападающий может попытаться переместиться внутри сети и атаковать другие системы. Возможен также сценарий отказа в обслуживании: специфичные запросы могут вызвать аварийное завершение процесса Redis, что нарушит работу приложений, полагающихся на эту базу.
Разработчики Redis уже выпустили исправления. Для коммерческой версии (Redis Software) обновления доступны в сборках 8.0.10-64, 7.22.2-79, 7.8.6-253, 7.4.6-279 и 7.2.4-153. Для открытых версий OSS и CE патчи включены в релизы 6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3 и 8.6.3. Кроме того, для модулей RedisTimeSeries и RedisBloom выпущены отдельные исправления: time series v1.12.14, v1.10.24, v1.8.23, а для Bloom - v2.8.20, v2.6.28, v2.4.23. Те пользователи, которые арендуют облачный сервис Redis Cloud, уже защищены - обновления установлены на стороне провайдера. Им не нужно предпринимать никаких действий.
Для самостоятельного администрирования рекомендуется как можно скорее обновить базу до последней версии. Кроме того, важно ограничить сетевой доступ к Redis только доверенными хостами с помощью брандмауэра. Стоит включить режим protected-mode, который блокирует внешние подключения, если пароль не задан. И конечно, необходимо использовать надёжную аутентификацию и выдавать пользователям минимально необходимые права. Например, запретить выполнение команды RESTORE обычным приложениям, если она не требуется.
Разработчики предупреждают: на данный момент нет данных о том, что эти уязвимости используются в реальных атаках. Однако это не повод откладывать обновление. Ошибки в Redis регулярно становятся целью злоумышленников, а учитывая, что уязвимости связаны с выполнением произвольного кода, риск крайне высок. Администраторы баз данных должны подойти к задаче с максимальной серьёзностью.
В заключение отметим, что все пять уязвимостей были обнаружены независимыми исследователями безопасности в рамках программ Bug Bounty. Их имена перечислены в официальном бюллетене. Это напоминает о том, насколько важна роль сообщества в поиске "дыр" в популярном программном обеспечении. Если вы используете Redis в своей инфраструктуре, сейчас самое время проверить версии и установить патчи. Не дожидайтесь, пока кто-то другой сделает это за вас - и, возможно, не по своей воле.
