Redis пусна седем корекции за сигурност на 23 юли, след като изследователи публикуваха концептуални доказателства (PoC) за отдалечено изпълнение на код (RCE) с автентификация за стандартните версии на Redis 6.2.22, 7.4.9, 8.6.4 и 8.8.0.

И четирите вериги изискват командата RESTORE. Веригите в Streams се нуждаят също от EVAL и XGROUP; веригата за 8.8.0 изисква EVAL и включения модул RedisBloom. От Redis заявяват, че основните дефекти в паметта могат да доведат до отдалечено изпълнение на код.

Redis 6.2.23, 7.2.15 и 7.4.10 отстраняват уязвимостта use-after-free, свързана със споделен NACK в Streams; Redis 8.2.8, 8.4.5 и 8.6.5 коригират както проблема в Streams, така и записите извън границите (out-of-bounds) в RedisBloom и TDigest; Redis 8.8.1 коригира зареждащите модули на RedisBloom и TDigest, докато защитата за Streams вече присъстваше в Redis 8.8.0.

Две от целевите версии за PoC, Redis 6.2.22 и 7.4.9, бяха част от майските обновления за сигурност, които Redis препоръча на потребителите да инсталират, но тези версии не включваха защитата за собственост на споделен NACK.

Препоръчва се обновяване до коригираната версия за внедрения клон. Дотогава оттеглете правата за RESTORE от акаунти, които не се нуждаят строго от тях, и блокирайте ненадеждния мрежов достъп. Ограничаването на RESTORE прекъсва и двата разкрити пътя.

Нито бележките по изданието на Redis от 23 юли, нито разгледаните публични PoC хранилища съобщават за експлоатация в реална среда към 24 юли 2026 г.

Пътят в Redis Streams е свързан с грешка в споделената собственост. Повреден RDB обект може да накара двама потребители да сочат към един и същ запис за чакащ запис, така че премахването на двамата потребители освобождава един и същ обект два пъти.

Публикуваният скрипт е проектиран да превърне полученото компрометиране на паметта в произволен достъп до паметта и в крайна сметка да извика функцията system().

Пътят в RedisBloom е запис извън границите в зареждащия модул TDigest RDB. Зареждащият модул заделя памет от една сериализирана стойност, но се доверява на отделно поле за капацитет, контролирано от атакуващия, когато решава колко данни да зареди.

Скриптът за Redis 8.8.0 е проектиран да превърне това несъответствие в примитиви за четене и запис, да извлече адреси на Redis и libc и да извика system().

Първият път е в Redis Streams. Повреден RDB обект може да накара двама потребители да сочат към един и същ запис за чакащ запис, представен вътрешно чрез streamNACK. Премахването на първия потребител освобождава обекта и оставя втория с висящ показалец. След това скриптовете премахват и втория потребител. Един блок, две освобождавания.

Бележките към изданието на Redis 8.6.4 цитират PR #15081. Преглед на изходния код от The Hacker News обаче установи, че в маркирания изходен код на версия 8.6.4 липсва проверката за дублирана собственост, добавена от тази промяна. Защитата се появява в Redis 8.6.5, пуснат на 23 юли.

Публикуваният скрипт за Redis 8.6.4 е проектиран да превърне двойното освобождаване в произволен достъп до паметта, след което да манипулира хеш функция на базата данни, така че специално създадена GET заявка да извика system(). Той възстановява показалеца и проверява дали Redis все още реагира.

Вторият път се намира в зареждащия модул RedisBloom TDigest RDB. Той заделя своите масиви от центроиди от сериализирана стойност за компресия, след което се доверява на отделно поле за капацитет, контролирано от атакуващия, при вземането на решение колко възли могат да бъдат заредени. Малко реално заделяне на памет, съчетано с преувеличени метаданни, води до запис извън границите.

Скриптът за Redis 8.8.0 е проектиран да превърне записа в примитиви за четене и запис, да извлече адреси на Redis и libc и да манипулира хеш функция на базата данни, така че специално създадена GET заявка да извика system(). Друго публикувано концептуално доказателство демонстрира същата основна причина и верига за отдалечено изпълнение на код с автентификация срещу Redis 8.8.0.

Корекцията на Redis изисква зареденият капацитет на TDigest да съответства на заделената памет, получена от стойността на компресията. Тя също така поставя граници на броячите на сляти и несляти възли преди четенето на масивите.

  • Седем версии, без нови CVE записи: Хранилището определя проблема в Streams като част от „семейство на непълни корекции“ за CVE-2026-25589, но Redis свързва това CVE с компрометиране на паметта в RedisBloom по време на RESTORE, а не с дефекта със споделен NACK в Streams. Бележките към юлското издание на Redis не посочват CVE или CVSS оценка за нито един от двата нови класа грешки.
  • Към 24 юли търсенията от страна на The Hacker News не откриха отделен NVD запис за юлските констатации за споделен NACK или TDigest. NVD все още показваше майските записи за CVE-2026-25243 и CVE-2026-25589. Търсене в каталога с известни експлоатирани уязвимости на CISA не върна резултат за нито един от двата идентификатора.

Разкритието следва друга открита от изкуствен интелект RCE уязвимост в Redis, коригирана през май. Bera Buddies се самоопределя като „изследвания на AI агенти“. Чаофан Шоу заяви в X, че агентите Kimi K3 са открили 19 уязвимости от тип нулев ден в Redis за около 90 минути и добави, че друго изпълнение е създало експлойт за Redis 8.8.0 за 27 минути.

Тези броеве, времеви рамки и твърдяната степен на автономност остават съобщени от самите автори. Публичните данни на Redis потвърждават дефектите и корекциите за сигурност. Те обаче не потвърждават твърдения брой уязвимости от тип нулев ден, нито доколко самостоятелно са работили агентите.

Версиите Redis 6.2.22 и 7.4.9 бяха целта през май. До юли и двете се нуждаеха от ново обновяване. Проверете точната версия на внедрения клон, а не просто дали за Redis наскоро са били инсталирани корекции за сигурност.