- 27,288
- 46
- 8 Ноя 2022
Полное описание эксплойта уже лежит в интернете.
В Redis нашли опасную ошибку, которая больше двух лет оставалась незамеченной и теперь получила подробное публичное описание. Уязвимость позволяет пользователю с доступом к базе данных выполнять команды операционной системы на сервере, где запущен Redis. Проблему обнаружил автономный инструмент на основе искусственного интеллекта , созданный для поиска ошибок в крупных кодовых базах.
Уязвимость CVE-2026-23479 (CVSS:2.0/AV:N/AC:L/Au:S/C:C/I:C/A:C — 9.0 (High)) появилась в Redis 7.2.0 и затронула все стабильные ветки до исправлений, выпущенных 5 мая. О находке сообщила Team Xint Code, а полное техническое описание уже опубликовано.
Ситуацию осложняет популярность Redis в облачной инфраструктуре. По оценке Wiz, Redis встречается в большинстве облачных сред, причём многие экземпляры работают без пароля. Чтобы атаковать, нужно войти в систему, но при стандартной настройке пользователь по умолчанию уже имеет все права, нужные для цепочки эксплуатации.
Ошибка находится в функции unblockClientOnKey() в файле src/blocked.c. Функция срабатывает, когда событие по ключу пробуждает заблокированную команду. Redis передаёт ожидающую команду в processCommandAndResetClient(), а затем продолжает использовать тот же указатель на клиента. Проблема в том, что вызванная функция может освободить память клиента, о чём прямо сказано в комментарии к её описанию. Вызывающий код игнорирует возвращаемое значение и снова обращается к уже освобождённой структуре.
По данным Wiz, уязвимость появилась из-за двух изменений в коде. В январе 2023 года, когда переработали код, добавили вызов, не проверив результат. В марте 2023 года другое изменение добавило дополнительные обращения к клиенту после этого вызова. По отдельности оба изменения не создавали опасной ситуации, но вместе попали в Redis 7.2.0 и прошли несколько проверок безопасности.
Цепочка атаки начинается с утечки адреса в памяти. Затем злоумышленник освобождает структуру клиента и подставляет на её место поддельную. После этого штатный механизм Redis, который учитывает память, используется против самого сервера, чтобы перезаписать указатель на функцию.
Опубликованный вариант атаки проходит в три этапа. Сначала короткий сценарий Lua раскрывает указатель в памяти. Затем злоумышленник настраивает ограничения памяти клиента, помещает разросшийся клиент в ожидание на потоке данных, снижает ограничения и пробуждает его. Redis освобождает заблокированный клиент во время выполнения вызова, а следующая команда SET сразу занимает освободившееся место поддельной структурой. На последнем этапе Redis, обновляя учёт памяти, записывает данные за пределами ожидаемой области и перенаправляет вызов strcasecmp() на system(). После этого следующая команда, которую разбирает Redis, выполняется как команда оболочки.
Официальный образ Redis для Docker упрощает финальную часть атаки. В нём включена только частичная защита RELRO, поэтому глобальная таблица смещений остаётся доступной для записи во время работы. Рандомизация адресного пространства и позиционно-независимый исполняемый файл в данном случае не спасают, поскольку запись выполняется относительно глобального объекта с фиксированным смещением в собранной версии.
Для полной атаки нужен сеанс с правами на CONFIG SET, EVAL, команды потоков XREAD и XADD, а также базовые команды SET и GET. В терминах списков контроля доступа Redis это категории @admin, @scripting, @stream, @read и @write. Пользователь по умолчанию имеет все эти возможности, а во многих средах такие права объединены в одну общую роль приложения или оператора. Запрет CONFIG ломает опубликованную цепочку, но не устраняет саму ошибку обращения к освобождённой памяти.
Team Xint Code показала рабочее выполнение кода на ZeroDay.Cloud 2025, соревновании Wiz по взлому, которое прошло в Лондоне в декабре 2025 года.
Redis заявила , что не замечает признаков того, что уязвимость эксплуатируют в её средах и у клиентов. На момент публикации открытых сообщений об атаках в реальных условиях также не было. Но полное техническое описание уже доступно, поэтому риск повторного использования цепочки другими злоумышленниками вырос.
Пользователям Redis рекомендуют обновиться до исправленной версии своей ветки: 7.2.14, 7.4.9, 8.2.6, 8.4.3 или 8.6.3. Все версии вышли 5 мая. Небольшие обновления внутри одной ветки можно установить без сложной миграции. Управляемые облачные сервисы обновляются по собственному графику, а Redis Cloud, по заявлению Redis, уже получила исправление.
Если быстро установить обновление нельзя, Redis не должен быть доступен из открытого интернета. Доступ лучше закрыть за TLS, а права разделить так, чтобы одна роль не совмещала @admin, CONFIG и @scripting. Если Lua не используется, категорию @scripting стоит отключить: это убирает первый этап опубликованной атаки с утечкой адреса памяти.
В первую очередь стоит проверить экземпляры Redis, доступные из интернета, общие учётные данные приложений и роли, где одновременно есть CONFIG, сценарии Lua и доступ к потокам данных. Общие пароли и ключи доступа лучше заменить.
CVE-2026-23479 стала одной из пяти уязвимостей Redis с риском удалённого выполнения кода, раскрытых в прошлом месяце. Она также появилась вскоре после RediShell , другой ошибки Redis 2025 года, связанной с обращением к освобождённой памяти и сценариями Lua. В новом случае особенно показательно, что ошибку нашли не когда проверяли код обычным образом, а с помощью автономного инструмента на основе искусственного интеллекта: две правки создали проблему, два года она оставалась в одном из самых распространённых хранилищ данных, а всплыла только на соревновании по взлому.
В Redis нашли опасную ошибку, которая больше двух лет оставалась незамеченной и теперь получила подробное публичное описание. Уязвимость позволяет пользователю с доступом к базе данных выполнять команды операционной системы на сервере, где запущен Redis. Проблему обнаружил автономный инструмент на основе искусственного интеллекта , созданный для поиска ошибок в крупных кодовых базах.
Уязвимость CVE-2026-23479 (CVSS:2.0/AV:N/AC:L/Au:S/C:C/I:C/A:C — 9.0 (High)) появилась в Redis 7.2.0 и затронула все стабильные ветки до исправлений, выпущенных 5 мая. О находке сообщила Team Xint Code, а полное техническое описание уже опубликовано.
Ситуацию осложняет популярность Redis в облачной инфраструктуре. По оценке Wiz, Redis встречается в большинстве облачных сред, причём многие экземпляры работают без пароля. Чтобы атаковать, нужно войти в систему, но при стандартной настройке пользователь по умолчанию уже имеет все права, нужные для цепочки эксплуатации.
Ошибка находится в функции unblockClientOnKey() в файле src/blocked.c. Функция срабатывает, когда событие по ключу пробуждает заблокированную команду. Redis передаёт ожидающую команду в processCommandAndResetClient(), а затем продолжает использовать тот же указатель на клиента. Проблема в том, что вызванная функция может освободить память клиента, о чём прямо сказано в комментарии к её описанию. Вызывающий код игнорирует возвращаемое значение и снова обращается к уже освобождённой структуре.
По данным Wiz, уязвимость появилась из-за двух изменений в коде. В январе 2023 года, когда переработали код, добавили вызов, не проверив результат. В марте 2023 года другое изменение добавило дополнительные обращения к клиенту после этого вызова. По отдельности оба изменения не создавали опасной ситуации, но вместе попали в Redis 7.2.0 и прошли несколько проверок безопасности.
Цепочка атаки начинается с утечки адреса в памяти. Затем злоумышленник освобождает структуру клиента и подставляет на её место поддельную. После этого штатный механизм Redis, который учитывает память, используется против самого сервера, чтобы перезаписать указатель на функцию.
Опубликованный вариант атаки проходит в три этапа. Сначала короткий сценарий Lua раскрывает указатель в памяти. Затем злоумышленник настраивает ограничения памяти клиента, помещает разросшийся клиент в ожидание на потоке данных, снижает ограничения и пробуждает его. Redis освобождает заблокированный клиент во время выполнения вызова, а следующая команда SET сразу занимает освободившееся место поддельной структурой. На последнем этапе Redis, обновляя учёт памяти, записывает данные за пределами ожидаемой области и перенаправляет вызов strcasecmp() на system(). После этого следующая команда, которую разбирает Redis, выполняется как команда оболочки.
Официальный образ Redis для Docker упрощает финальную часть атаки. В нём включена только частичная защита RELRO, поэтому глобальная таблица смещений остаётся доступной для записи во время работы. Рандомизация адресного пространства и позиционно-независимый исполняемый файл в данном случае не спасают, поскольку запись выполняется относительно глобального объекта с фиксированным смещением в собранной версии.
Для полной атаки нужен сеанс с правами на CONFIG SET, EVAL, команды потоков XREAD и XADD, а также базовые команды SET и GET. В терминах списков контроля доступа Redis это категории @admin, @scripting, @stream, @read и @write. Пользователь по умолчанию имеет все эти возможности, а во многих средах такие права объединены в одну общую роль приложения или оператора. Запрет CONFIG ломает опубликованную цепочку, но не устраняет саму ошибку обращения к освобождённой памяти.
Team Xint Code показала рабочее выполнение кода на ZeroDay.Cloud 2025, соревновании Wiz по взлому, которое прошло в Лондоне в декабре 2025 года.
Redis заявила , что не замечает признаков того, что уязвимость эксплуатируют в её средах и у клиентов. На момент публикации открытых сообщений об атаках в реальных условиях также не было. Но полное техническое описание уже доступно, поэтому риск повторного использования цепочки другими злоумышленниками вырос.
Пользователям Redis рекомендуют обновиться до исправленной версии своей ветки: 7.2.14, 7.4.9, 8.2.6, 8.4.3 или 8.6.3. Все версии вышли 5 мая. Небольшие обновления внутри одной ветки можно установить без сложной миграции. Управляемые облачные сервисы обновляются по собственному графику, а Redis Cloud, по заявлению Redis, уже получила исправление.
Если быстро установить обновление нельзя, Redis не должен быть доступен из открытого интернета. Доступ лучше закрыть за TLS, а права разделить так, чтобы одна роль не совмещала @admin, CONFIG и @scripting. Если Lua не используется, категорию @scripting стоит отключить: это убирает первый этап опубликованной атаки с утечкой адреса памяти.
В первую очередь стоит проверить экземпляры Redis, доступные из интернета, общие учётные данные приложений и роли, где одновременно есть CONFIG, сценарии Lua и доступ к потокам данных. Общие пароли и ключи доступа лучше заменить.
CVE-2026-23479 стала одной из пяти уязвимостей Redis с риском удалённого выполнения кода, раскрытых в прошлом месяце. Она также появилась вскоре после RediShell , другой ошибки Redis 2025 года, связанной с обращением к освобождённой памяти и сценариями Lua. В новом случае особенно показательно, что ошибку нашли не когда проверяли код обычным образом, а с помощью автономного инструмента на основе искусственного интеллекта: две правки создали проблему, два года она оставалась в одном из самых распространённых хранилищ данных, а всплыла только на соревновании по взлому.
- Источник новости
- www.securitylab.ru
