Наскоро публикувано изследване, свързано с AI агента Kimi K3, разкри множество пътища за отдалечено изпълнение на код (RCE) след удостоверяване в Redis – едно от най-широко внедряваните хранилища на данни в оперативната памет в света.

Констатациите, споделени от изследователя с псевдоним Bera Buddies, обхващат официалните версии на Redis 6.2.22, 7.4.9, 8.6.4 и 8.8.0. Те съчетават проблем с двойно освобождаване на паметта (double-free) при споделен NACK в потребителски групи на потоци (stream consumer groups) с отделно препълване на купчината (heap overflow) в интегрирания модул RedisBloom TDigest.

Изследователите описват безразрушително отдалечено изпълнение на код срещу официалните Docker изображения на Redis. Налице са два отделни класа уязвимости:

  • Двойно освобождаване на памет при Stream NACK (фамилия с непълна корекция CVE-2026-25589) – Засяга версии 6.2.22, 7.4.9 и 8.6.4. Пътят на споделения NACK в потребителските групи на потоци може да освободи един и същ блок от купчината два пъти, осигурявайки на удостоверен клиент надежден примитив за изпълнение на код.
  • Препълване на купчината при TDigest (RedisBloom, интегриран в 8.8.0) – Във версия Redis 8.8.0 проблемът с NACK е адресиран, но новооткрито препълване на купчината в имплементацията на TDigest по подразбиране все още позволява отдалечено изпълнение на код върху нов инстанс.

И двата пътя изискват команди, които обикновено остават разрешени при вътрешни внедрявания: EVAL, RESTORE и XGROUP. Версия 8.8.0 също така се нуждае от вградения модул RedisBloom, който се доставя по подразбиране.

Redis често се намира зад приложни слоеве с парола, но с напълно достъпни команди. След като атакуващият придобие идентификационни данни – чрез изтичане на тайни, SSRF или лошо конфигуриран мрежов ACL – той може да премине от „достъп до хранилището за данни“ към командна обвивка на ниво хост, без да срива услугата по начин, който винаги изглежда като атака.

Изследването подчертава, че двойното освобождаване при споделен NACK е напълно коригирано едва във версия 8.8.0. По-старите поддържани версии остават уязвими, ако операторите не са инсталирали съответните корекции за сигурност. В същото време версия 8.8.0 не е автоматично защитена: уязвимостта в TDigest е описана като неотстранена в интегрирания модул към момента на оповестяването.

Чувствителността към разположението на паметта във версия 8.8.0 е важен детайл. Пътят на TDigest разчита на разпръскване на структури (spraying), за да се изгради детерминирано оформление на jemalloc, така че успеваемостта е най-висока при нов инстанс с минимален паралелен трафик – условия, които все пак съответстват на много тестови среди, среди за непрекъсната интеграция (CI) и слабо натоварени производствени контейнери.

Остатъците след експлоатация могат да оставят неактивни ключове или повредени структури. Операторите са предупредени да не изпълняват сляпо команди като FLUSHALL/SAVE на компрометиран хост с версия 8.8.0, без да разбират остатъчното състояние.

Докато разработчикът не пусне корекции за сигурност за всеки клон и за модула RedisBloom:

  • Обновете към коригирани версии на Redis веднага след като бъдат публикувани; не приемайте, че 8.8.0 е напълно безопасен, ако Bloom/TDigest остава уязвим.
  • Ограничете опасните команди чрез преименуване (rename-command) за EVAL, RESTORE и свързаните с тях администраторски примитиви, или използвайте Redis ACL, за да ги забраните за потребителите на приложенията.
  • Мрежова изолация – свържете Redis само с частни интерфейси; никога не излагайте порт 6379 към интернет.
  • Силна автентикация и хигиена на тайните – уникални пароли, без идентификационни данни по подразбиране и ротация след всяко подозрение за изтичане на информация.
  • Одит на модулите – деактивирайте или премахнете RedisBloom/TDigest, ако не се използват.
  • Следете за необичайна употреба на XGROUP/RESTORE/EVAL и неочаквани ключове в директориите с данни.

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

Организациите, използващи Redis версии от 6.2 до 8.8, трябва да опишат своите версии, да ограничат достъпните команди и да проследяват официалните бюлетини за сигурност на Redis и RedisBloom за пълно отстраняване на проблемите.