Давняя критическая уязвимость в системе управления базами данных Redis, оставшаяся незамеченной в течение 13 лет, ставит под угрозу безопасность десятков тысяч серверов по всему миру. Речь идет о баге, который позволяет злоумышленнику, получившему доступ к Redis, выполнить произвольный код на сервере за пределами защищенной среды. Проблема получила идентификатор CVE-2025-49844 и оценена по шкале CVSS на максимальные 10 баллов — это подчеркивает ее исключительную степень опасности.
Redis (Remote Dictionary Server) — это высокопроизводительная, нереляционная NoSQL СУБД, широко используемая в веб-разработке и облачных средах. Основное преимущество Redis — хранение данных в оперативной памяти, благодаря чему достигается мгновенный доступ к информации и высокая скорость операций. Однако именно широкое распространение делает уязвимость особенно опасной: по оценкам специалистов, Redis используется примерно в 75% облачных инфраструктур.
Уязвимость затрагивает все версии Redis, поддерживающие язык сценариев Lua. Суть проблемы — ошибка типа Use-After-Free, возникающая при неправильной работе механизма сборки мусора в интерпретаторе Lua. Через манипуляции с памятью злоумышленник может выйти за пределы «песочницы» и получить контроль над сервером. После успешной атаки хакеры могут красть учетные данные, устанавливать вредоносные программы, майнеры криптовалют или проникать в другие системы внутри сети.
Особую тревогу вызывает тот факт, что по состоянию на август 2025 года в интернете доступно около 330 тысяч экземпляров Redis, из которых примерно 60 тысяч не требуют аутентификации. Это означает, что доступ к ним можно получить без ввода логина и пароля, что сильно упрощает задачу потенциальным злоумышленникам. Более того, специалисты Trend Micro сообщают о наличии свыше 2 тысяч серверов с искусственным интеллектом, использующих Redis без какой-либо защиты.
Исследователи из компании Wiz, Бенни Айзекс и Нир Браха, стали первыми, кто обнаружил эту брешь. Они подчеркивают, что отсутствие своевременного исправления может привести к масштабным последствиям, особенно в тех случаях, когда экземпляры Redis доступны из интернета. По их словам, организациям необходимо как можно скорее установить обновления, отключить поддержку Lua и необязательных команд, включить аутентификацию и убедиться, что Redis работает с ограниченными правами — желательно не от имени root.
Хорошая новость заключается в том, что пользователи управляемого сервиса Redis Cloud могут чувствовать себя в безопасности — разработчики уже применили соответствующие патчи. Однако те, кто самостоятельно администрирует Redis, должны установить обновления вручную. Представитель Redis, директор по информационной безопасности Риаз Лахани, сообщил, что на данный момент не зафиксировано случаев эксплуатации уязвимости в Redis Cloud или у клиентов компании. Тем не менее, учитывая, как долго баг оставался нераскрытым, пренебрегать мерами предосторожности не стоит.
Cама уязвимость не может быть использована без аутентифицированного доступа, что несколько снижает вероятность атаки. Но в условиях, когда десятки тысяч экземпляров не защищены никакой формой авторизации, риск все еще остается крайне высоким. Хакеры могут использовать автоматические сканеры для поиска таких открытых серверов, после чего развернуть атаку с минимальными усилиями.
Важно отметить, что Redis давно используется в качестве кэш-системы, брокера сообщений и базы данных в таких известных платформах, как GitHub, Twitter, Stack Overflow, а также в многочисленных стартапах и корпоративных системах. Это делает потенциальный вектор атаки особенно широким: от утечек пользовательских данных до компрометации бизнес-приложений.
Кроме того, Redis часто применяется в микросервисной архитектуре и контейнеризированных средах, таких как Kubernetes. В таких случаях атака на Redis может стать трамплином для дальнейшего распространения вредоносного кода по всей инфраструктуре. Именно поэтому организации должны не только обновить Redis, но и провести аудит своих DevOps-процессов, чтобы исключить автоматическое развертывание уязвимых конфигураций.
Также стоит напомнить, что Redis по умолчанию не предполагает высокого уровня безопасности — изначально он был создан как решение для использования внутри защищенной сети. Однако в современных реалиях, когда все больше сервисов мигрируют в облако, забывать о безопасности конфигурации — недопустимо.
Если отключить поддержку Lua невозможно по архитектурным соображениям, следует ограничить набор выполняемых команд, внедрить принудительную аутентификацию, использовать брандмауэры и ограничение доступа по IP. Это поможет минимизировать вероятность успешной эксплуатации уязвимости, даже если обновление пока не установлено.
Наконец, системным администраторам рекомендуется использовать инструменты мониторинга активности Redis и настроить уведомления при подозрительных действиях, таких как выполнение нестандартных скриптов или неожиданные изменения в конфигурации. Также важно регулярно проверять журнал безопасности на предмет попыток вторжений.
Нынешняя ситуация вокруг Redis демонстрирует, насколько опасной может быть недооцененная уязвимость в популярном ПО с открытым исходным кодом. И хотя пока нет подтвержденных случаев эксплуатации, промедление в установке патчей может обернуться серьезными последствиями. Поддержание безопасности в условиях постоянно меняющейся цифровой среды требует не только своевременного обновления, но и стратегического подхода к архитектуре систем.
