5 травня Redis випустив виправлення для п’яти вразливостей класу RCE, найсерйозніша з яких — CVE-2026-23479 — отримала оцінку CVSS 8.8 за версією NVD (v3.1). Це помилка типу use-after-free (CWE-416), що була присутня в усіх стабільних гілках Redis, починаючи з версії 7.2.0, — понад два роки. Публічний експлойт уже доступний, хоча випадків експлуатації в реальних атаках поки не зафіксовано. Усім адміністраторам Redis-інстансів необхідно оновитися до версій 7.2.14, 7.4.9, 8.2.6, 8.4.3 або 8.6.3, а за неможливості негайного оновлення — обмежити ACL-привілеї та мережевий доступ до сервера.
Технічна суть вразливості
Вразливість знаходиться у функції unblockClientOnKey() у файлі src/blocked.c. Ця функція викликається під час пробудження заблокованої команди за подією ключа. Вона передає поставлену в чергу команду через processCommandAndResetClient(), а потім продовжує використовувати той самий вказівник на клієнтську структуру. Проблема в тому, що processCommandAndResetClient() може звільнити клієнта як побічний ефект — про це прямо сказано в коментарі до заголовка функції. Код, що викликає, ігнорує значення, яке повертається, і звертається до вже звільненої пам’яті.
За даними дослідників, баг виник унаслідок взаємодії двох комітів. Рефакторинг у січні 2023 року (PR #11012) додав виклик без перевірки результату. Зміна в березні 2023 року (PR #11568) додала додатковий доступ до клієнтської структури після цього виклику. Жоден із комітів окремо не створював вразливість — небезпечною стала саме їхня комбінація, що потрапила у відкритий доступ із версією 7.2.0.
Redis оцінює вразливість за CVSS 4.0 на рівні 7.7, що нижче за оцінку NVD. Розбіжність пояснюється відмінностями методологій оцінювання версій 3.1 і 4.0, а не суперечками щодо серйозності.
Опублікований ланцюжок експлуатації
Повний технічний опис експлойта уже опубліковано. Як повідомляється, ланцюжок атаки складається з трьох етапів:
- Витік адреси купи. Однорядковий Lua-скрипт (
EVAL "return tostring(redis.call)" 0) повертає вказівник на купу, необхідний для подальших обчислень. - Підміна клієнтської структури. Зловмисник маніпулює лімітами пам’яті клієнта, блокує «роздутий» клієнт на потоці (stream), потім скидає ліміти та пробуджує його. Redis звільняє заблокованого клієнта посеред обробки, а конвеєрна команда SET негайно займає звільнений слот підробленою клієнтською структурою.
- Перезапис вказівника функції. Штатний механізм обліку пам’яті в
updateClientMemoryUsage()виконує вихід за межі масиву з декрементом, використовуючи контрольовані зловмисником поля. Ціль — таблиця глобальних зміщень (GOT): перенаправленняstrcasecmp()наsystem(). Наступна команда, яку Redis розбирає, виконується як shell-команда.
Офіційний Docker-образ Redis, за даними дослідників, постачається з частковим RELRO, залишаючи GOT доступною для запису під час виконання. ASLR і PIE не допомагають, оскільки запис виконується відносно глобальної змінної з фіксованим зміщенням на етапі збирання.
Вимоги до експлуатації та масштаб загрози
Повний ланцюжок експлойта вимагає автентифікованої сесії з привілеями CONFIG SET, EVAL, потокових команд (XREAD/XADD) і базових SET/GET. У термінах ACL Redis це категорії @admin, @scripting, @stream, @read і @write. Користувач за замовчуванням має всі ці привілеї.
Вразливість виявила команда Team Xint Code. Компанія Theori описує Xint Code як автономний інструмент безпеки на основі ШІ, призначений для пошуку помилок у великих кодових базах. Це показовий випадок: два коміти створили вразливість, вона пройшла через багато раундів code review за два роки, і зрештою її знайшов не людина, а автоматизований інструмент у межах хакерського змагання.
Redis заявив про відсутність свідчень експлуатації у власних середовищах або середовищах клієнтів. На момент публікації повідомлень про експлуатацію в реальних атаках не надходило. Втім, публікація повного технічного ланцюжка суттєво підвищує ризик подальшої експлуатації.
Практичні рекомендації
Пріоритет — негайне оновлення. Встановіть виправлені версії для вашої серії:
- Redis 7.2 → 7.2.14
- Redis 7.4 → 7.4.9
- Redis 8.2 → 8.2.6
- Redis 8.4 → 8.4.3
- Redis 8.6 → 8.6.3
Redis Cloud, за заявою вендора, уже оновлено. Керовані сервіси інших провайдерів оновлюються за власними графіками — уточніть статус у свого провайдера.
Якщо негайне оновлення неможливе:
- Усуньте прямий доступ до Redis з інтернету, забезпечте доступ лише через TLS.
- Розділіть ACL-привілеї: жодна роль не повинна одночасно мати
@admin, CONFIG і@scripting. - Забороніть категорію
@scripting, якщо Lua-скрипти не використовуються — це блокує перший етап ланцюжка (витік адреси купи). - Заборона CONFIG ламає конкретний опублікований ланцюжок, але не усуває базову помилку use-after-free.
- Проведіть ротацію всіх спільних облікових даних Redis.
Насамперед зверніть увагу на інстанси, доступні з інтернету, на спільні облікові записи застосунків і на будь-які ролі, що поєднують доступ до CONFIG, скриптів і потоків.
CVE-2026-23479 — одна з п’яти вразливостей класу RCE, розкритих в одному пакеті оновлень Redis, і друга за останній час помилка use-after-free в Redis, пов’язана з Lua-скриптингом. Наявність публічного PoC за масового розгортання Redis робить вікно для безпечного оновлення вкрай вузьким. Оновіть уражені інстанси до виправлених мінорних версій зараз, а не після появи перших звітів про атаки.
