У Redis виправили критичну уразливість CVE-2025-49844, якій присвоєно CVSS 10,0. Помилка класу use-after-free існувала в кодовій базі близько 13 років і експлуатується через вбудований за замовчуванням механізм Lua-скриптингу. Дослідники Wiz назвали експлойт RediShell і продемонстрували його на Pwn2Own Berlin 2025, що підкреслює практичну здійсненність атаки проти широкого спектру розгортань Redis.
Як працює атака: use-after-free та обход пісочниці Lua
Зловмисник, маючи автентифікований доступ до інстансу Redis (або взагалі без автентифікації в уразливих конфігураціях), може виконати спеціально сформований Lua-скрипт і вийти за межі пісочниці. Далі провокується use-after-free — ситуація, коли програма повторно використовує звільнену ділянку пам’яті. Це дає змогу перехопити керування процесом і реалізувати повноцінне віддалене виконання коду (RCE) на хості, зокрема розгорнути реверс-шелл, закріпитися в системі й продовжити розвиток атаки.
Масштаб загрози: інтернет-експозиція та дефолтний Lua
За оцінкою Wiz, уразливість зачіпає всі підтримувані версії Redis із активним скриптингом Lua, оскільки коренева причина пов’язана з базовим інтерпретатором Lua. Інтернет-сканування виявило близько 330 000 публічно доступних інстансів Redis, щонайменше 60 000 з них не потребують автентифікації. Така експозиція, помножена на ввімкнений за замовчуванням Lua-движок, суттєво знижує бар’єр для атаки та підвищує ризик для організацій.
Технічний розбір: типовий ланцюжок компрометації
Практичний сценарій виглядає так: зловмисник надсилає шкідливий Lua-скрипт (через команди на кшталт EVAL/EVALSHA), обходить обмеження пісочниці й ініціює use-after-free. Отримавши виконання коду, атакувальник здатен зібрати облікові дані, ексфільтрувати секрети з пам’яті та сховищ Redis, розгорнути вредоносне ПЗ і здійснювати бокове переміщення мережею. В хмарних середовищах це може означати ескалацію до контейнерів і вузлів оркестрації, а також доступ до суміжних сервісів. Демонстрація Wiz на Pwn2Own Berlin 2025 підтвердила, що «це дає атакувальному повний доступ до системи хоста».
Рекомендації: що зробити негайно
Оновлення та пріоритезація
Негайно встановіть офіційні патчі Redis, у першу чергу — на вузлах, доступних з інтернету, а також у середовищах із чутливими даними чи підвищеними привілеями. Оновлення мають охопити всі інстанси у production, тестових середовищах і CI/CD, аби виключити обхідні вектори через менш контрольовані контури.
Зміцнення конфігурації Redis
Увімкніть автентифікацію та ACL для кожного інстансу. Якщо сервіс експонується назовні, за можливості відключіть Lua-скриптинг та інші непотрібні функції. Запускайте Redis із мінімально необхідними привілеями (не від root), обмежте адміністративні команди (через ACL або rename-command), а також увімкніть деталізоване логування й аудит для подальшого розслідування інцидентів.
Мережевий периметр і спостережність
Обмежте мережевий доступ до довірених сегментів: застосовуйте міжмережеві екрани, списки контролю доступу та ізоляцію у VPC/вирізаних підмережах. Прив’язуйте Redis до внутрішніх інтерфейсів і закривайте публічний доступ. Налаштуйте моніторинг аномалій: різкі сплески активності Lua, невідомі вихідні з’єднання (індикатор реверс-шелла), нетипові команди та операції з пам’яттю. Рекомендується контролювати вихідний трафік (egress) і застосовувати правила виявлення на рівні IDS/EDR.
Організаціям варто терміново провести інвентаризацію інстансів Redis, застосувати оновлення безпеки, закрити непотрібний публічний доступ і відключити Lua на експонованих вузлах. Поєднання вчасних патчів, безпечної конфігурації та мережевої ізоляції істотно знижує ймовірність компрометації та обмежує наслідки потенційної атаки й подальшого
