Разработчики думали, что закрыли брешь, но хакеры с лёгкостью обошли заплатки.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Даже установленное исправление не всегда закрывает старую брешь полностью, и опубликованный набор демонстрационных эксплойтов показал удалённое выполнение команд в Redis 6.2.22, 7.4.9, 8.6.4, 8.8.0 и 8.8.1. Часть кода обходит ранее выпущенные исправления для CVE-2026-25243 и CVE-2026-25589 . Обе уязвимости имеют оценку 8.8 по шкале CVSS 3.1.
В версиях 6.2.22, 7.4.9 и 8.6.4 атака использует повторное освобождение участка памяти при обработке общих отрицательных подтверждений в группах потребителей Redis Streams. Такой сбой позволяет нарушить структуру памяти процесса и добиться выполнения команды на сервере. Представленный эксплойт работает несмотря на исправление CVE-2026-25243.
Для Redis 8.8.0 авторы применили отдельную ошибку переполнения памяти в структуре TDigest из встроенного модуля RedisBloom. Ещё один эксплойт затрагивает структуры TopK в Redis 8.8.0 и 8.8.1 и обходит неполное исправление CVE-2026-25589. После очистки части указателей функция удаления продолжала обращаться к элементам за пределами выделенного участка памяти.
Для запуска кода атакующему требуется возможность отправлять команды EVAL, RESTORE и XGROUP. Эксплойтам для ветки 8.8 также нужен встроенный RedisBloom. Демонстрации зависят от расположения объектов в памяти, поэтому авторы проверяли их на свежих официальных контейнерах без посторонних подключений и команд.
Во время испытаний эксплойты стабильно выполняли заданную команду на поддерживаемых версиях. Авторы называют код недеструктивным, однако после запуска в базе остаются служебные ключи и повреждённые структуры. Неверные смещения для нестандартной сборки также могут аварийно завершить Redis .
Набор опубликован только для санкционированного тестирования. Авторы рекомендуют запускать демонстрации на свежих изолированных экземплярах, отдельно рассчитывать смещения для неофициальных сборок и не сохранять состояние Redis 8.8.0 после эксплуатации ошибки TDigest.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Даже установленное исправление не всегда закрывает старую брешь полностью, и опубликованный набор демонстрационных эксплойтов показал удалённое выполнение команд в Redis 6.2.22, 7.4.9, 8.6.4, 8.8.0 и 8.8.1. Часть кода обходит ранее выпущенные исправления для CVE-2026-25243 и CVE-2026-25589 . Обе уязвимости имеют оценку 8.8 по шкале CVSS 3.1.
В версиях 6.2.22, 7.4.9 и 8.6.4 атака использует повторное освобождение участка памяти при обработке общих отрицательных подтверждений в группах потребителей Redis Streams. Такой сбой позволяет нарушить структуру памяти процесса и добиться выполнения команды на сервере. Представленный эксплойт работает несмотря на исправление CVE-2026-25243.
Для Redis 8.8.0 авторы применили отдельную ошибку переполнения памяти в структуре TDigest из встроенного модуля RedisBloom. Ещё один эксплойт затрагивает структуры TopK в Redis 8.8.0 и 8.8.1 и обходит неполное исправление CVE-2026-25589. После очистки части указателей функция удаления продолжала обращаться к элементам за пределами выделенного участка памяти.
Для запуска кода атакующему требуется возможность отправлять команды EVAL, RESTORE и XGROUP. Эксплойтам для ветки 8.8 также нужен встроенный RedisBloom. Демонстрации зависят от расположения объектов в памяти, поэтому авторы проверяли их на свежих официальных контейнерах без посторонних подключений и команд.
Во время испытаний эксплойты стабильно выполняли заданную команду на поддерживаемых версиях. Авторы называют код недеструктивным, однако после запуска в базе остаются служебные ключи и повреждённые структуры. Неверные смещения для нестандартной сборки также могут аварийно завершить Redis .
Набор опубликован только для санкционированного тестирования. Авторы рекомендуют запускать демонстрации на свежих изолированных экземплярах, отдельно рассчитывать смещения для неофициальных сборок и не сохранять состояние Redis 8.8.0 после эксплуатации ошибки TDigest.
- Источник новости
- www.securitylab.ru