Срочный патч Redis на BitrixVM закрывает дыру в команде RESTORE

В меню BitrixVM Redis уже «стоит», push и кеш вроде работают — и всё равно непонятно, закрыта ли дыра в команде RESTORE. CVE-2026-25243 смотрит не на крупный «Redis 8.2 в changelog», а на patch-level: для ветки 8.2 порог — не ниже 8.2.6.

Как проявляется риск на хосте

Симптом не всегда кричит в админке: redis-server крутится, клиенты Битрикс ходят за кешем и сессиями, а уязвимость сидит в команде RESTORE. В advisory GHSA-c8h9-259x-jff4 (опубликован 2026-05-05) описан invalid memory access: аутентифицированный злоумышленник с правом выполнить RESTORE подаёт специально сформированный сериализованный payload и может довести процесс до remote code execution. Это CVE-2026-25243.

Оценка тяжести: CVSS v4 7.7 (High) у GitHub CNA, CVSS v3.1 8.8 (High) у NVD. Два обязательных условия — логин в Redis и разрешение на RESTORE. Открытый 6379 без пароля усиливает картину, но дыра сформулирована не как анонимный RCE «с улицы».

В том же May SECURITY-релизе Redis закрыл соседние CVE вокруг Time Series, Bloom и RESTORE. Для парка BitrixVM ядро — 25243; остальные номера — контекст пакета, не отдельный runbook.

Почему «образ с Redis 8.2» ещё не ответ

Официальная матрица Redis blog для CVE-2026-25243 (OSS/CE): 6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3, 8.6.3. NVD в CPE пишет affected «до 8.6.3 не включая» — это не отменяет бэкпорты 8.2.6 и 8.4.3. На BitrixVM после 9.0.9 в документации и на странице скачивания фигурирует ряд Redis 8.2.x под push-server; в 9.0.0 ещё был redis 7.2. Практический порог типичного хоста — ≥ 8.2.6, а не прыжок на 8.6.3 только из заголовка NVD.

Образы 9.0.9 и 9.0.10 сами по себе не гарантируют redis_version ≥ 8.2.6: на download указан ряд 8.2.x без patch-level. «В changelog Redis 8.2» ≠ «пропатчено под CVE-2026-25243».

После May вышел SECURITY 8.2.8 (2026-07-23) с другими дырами. Целитесь на актуальный security-минор ветки, а не замирайте на первом May-билде. На момент advisory у Redis не было evidence of exploitation; публичного PoC и попадания в CISA KEV по проверке на 2026-08-16 нет — обновляйте спокойно по версиям, без паники «уже массово бьют».

Как проверить причину на каждом хосте

На каждом хосте пула и на отдельном push-node снимите redis-cli INFO server и поле redis_version (или grep по INFO). Сравните с порогом своей ветки: для 8.2 минимум — 8.2.6.

Пакеты окружения BitrixVM обновляют через /root/menu.sh → 1. Manage servers in the pool → Update packages on host (bitrix / all). Redis идёт как пакет окружения или ОС. Пункт «Update PHP, MySQL, PostgreSQL» Redis не трогает: документация отдельно подчёркивает, что PHP и MySQL с VM не обновляются «в куче» этим путём, и Redis к нему тоже не относится.

Не обещайте себе заранее, что yum или dnf Bitrix-репозитория уже отдаёт 8.2.6 или 8.2.8. После Update packages снова сверьте redis_version. Новый ISO 9.0.x без этой же проверки CVE не закрывает.

Как временно снизить риск, пока пакет не доехал

Workaround из advisory без бинарного патча: запретить RESTORE пользователям, которым команда не нужна. Типичный клиент Битрикс для кеша, сессий и push не обязан иметь RESTORE — это путь DUMP, миграций и admin-операций.

Направление: ACL SETUSER <user> -restore, затем проверка через ACL GETUSER / ACL LIST. У default user часто стоит +@all — как раз зона «лишних» команд. После патча бинарника ACL можно пересмотреть, но least-privilege остаётся полезным.

Сетевой контур из best practices Redis: не слушать публичный 6379 и 0.0.0.0 без нужды, strong auth, protected-mode. В ядре Битрикс (main 25.800.0) появилась поддержка password в Redis-коннекторе (.settings.php → AUTH) — это гигиена аутентификации, не фикс CVE-2026-25243.

Чем это не разлогин сессий на пике

Вытеснение сессий, maxmemory-policy и массовый разлогин на пике — отдельная история про ёмкость. Здесь угол другой: security-патч RESTORE и сверка redis_version по парку. Не смешивайте с фоновым CVE-2026-72568 (Cluster Bus PING, NVD 2026-08-10): другая дыра той же security-ленты Redis, не синоним 25243.

Как не пропустить отстающий Redis по парку

• redis_version ниже порога ветки (для 8.2: меньше 8.2.6 — минимум по CVE-2026-25243);
• Redis слушает не-loopback без ACL или пароля;
• у app-user в ACL LIST есть +restore или +@all без реальной нужды;
• аномальные краши и рестарты redis-server после крупных payload — только осторожный сигнал, без ложной атрибуции к CVE.

Частые вопросы

Достаточно ли записи «Redis 8.2» в changelog BitrixVM?

Нет. На образах 9.0.9+ указан ряд 8.2.x без гарантии patch-level. Фикс CVE-2026-25243 для этой ветки — не ниже 8.2.6; смотрите redis_version через redis-cli INFO server на каждом хосте.

Закроет ли дыру новый ISO или пункт Update PHP, MySQL, PostgreSQL?

Новый образ 9.0.x сам по себе CVE не закрывает без проверки redis_version. Обновлять Redis нужно через Update packages on host в /root/menu.sh. Пункт Update PHP, MySQL, PostgreSQL пакет Redis не ставит.

Можно ли временно снять риск без апгрейда бинарника?

Да, по advisory: ACL-запрет команды RESTORE (-restore) для пользователей, которым она не нужна. Типичному app/cache/session клиенту Битрикс RESTORE обычно не требуется. После установки security-минора ACL всё равно полезно держать по least-privilege.

Кто уязвим: нужен ли логин в Redis и право на RESTORE?

По advisory CVE-2026-25243 атакующему нужны аутентификация в Redis и разрешение выполнить RESTORE. Открытый порт без auth усиливает риск, но формулировка дыры — не анонимный RCE без этих двух условий.

Чем эта тема отличается от разлогина сессий на пике?

Разлогин на пике — про maxmemory, eviction и ёмкость сессий. Здесь — security-патч RESTORE (CVE-2026-25243), матрица 8.2.6 / 8.4.3 / 8.6.3 и сверка версий на BitrixVM. Это разные инциденты и разные проверки.

Как BX Pulse помогает не пропустить отстающий Redis

BX Pulse следит за доступностью и техническим состоянием проектов на 1С-Битрикс и помогает замечать отклонения до обращения клиента — в том числе когда по парку BitrixVM нужно быстро понять, где redis_version ещё ниже security-порога ветки. Добавьте первый сайт и настройте уведомления: https://bx-monitor.ru/.