27 октября 2026 года Aron Xu отправил в рассылку debian-security-announce письмо DSA-6586-1. В шапке бюллетеня указана Lena Voytek. Пакет один: valkey, база ключ-значение в памяти. Для стабильного выпуска, это Debian 13 (trixie), исправление названо прямо: 8.1.1+dfsg1-3+deb13u3. В письме семь CVE. Debian формулирует риск коротко: сервис можно уронить, а в части случаев на машине можно запустить чужой код.
На VPS с WordPress Valkey чаще всего держит object cache. Туда складывают результаты запросов к MariaDB, транзиенты, иногда сессии PHP. nginx, PHP-FPM и MariaDB этот пакет не обновляет. Если в dpkg -l нет пакетов valkey, бюллетень ваш кэш не касается. Если кэш поставлен пакетом redis, это другой исходный пакет: команда обновления valkey его не тронет.
Семь CVE в DSA-6586-1
Письмо само по себе короткое и отправляет за статусом на страницу valkey в трекере. Разбор по карточкам ниже оттуда же. Номера в бюллетене: CVE-2026-23479, CVE-2026-23631, CVE-2026-25243, CVE-2026-56684, CVE-2026-63639, CVE-2026-82631, CVE-2026-82677. Баги Debian в шапке: 1144956, 1144957 и 1146641.
CVE-2026-23479 нужен клиент, который уже может слать команды. Когда заблокированная команда выполняется снова, путь разблокировки не смотрит на ошибку processCommandAndResetClient. Если в этот момент клиента выкидывают, процесс обращается к уже освобождённой памяти (use-after-free). Дальше падение или чужой код. В заметках трекера сказано, что сценарий воспроизвели на пакете 8.1.1+dfsg1-3+deb13u2. Апстрим закрыл это в линии 8.1.7. В trixie номер 8.1.1 в имени пакета не поднимают: патч приезжает ревизией deb13u3.
CVE-2026-23631 про реплику. Снова нужен уже допущенный клиент, и ещё реплика, у которой replica-read-only выключен или его можно выключить. Через синхронизацию с мастером процесс можно уронить или запустить на нём чужой код. В карточке есть запасной путь: не давать пользователям скрипты Lua или не держать такую реплику. Одиночный Valkey под object cache WordPress репликой обычно не является. Эта карточка про схему с репликой, не про один локальный порт кэша.
CVE-2026-25243 и CVE-2026-63639 сходятся на команде RESTORE. В первой уже допущенный клиент с правом на эту команду подсовывает сериализованное значение. Проверка длины в zipmap не ловит слишком длинную кодировку, процесс читает за концом записи и может упасть или выполнить чужой код. В карточке запасной путь до пакета: закрыть RESTORE правилом ACL. Вторая карточка тоже RESTORE, но полезная нагрузка это битый поток RDB у стрима. Один NACK из списка ожидающих записей оказывается сразу у нескольких потребителей. Удаление одного, пока второй ещё держит эту запись, роняет процесс или даёт запустить код. Это баг 1144957. Апстрим закрыл его в 8.1.9.
Плагин object cache для WordPress сам RESTORE не вызывает. Ему хватает GET, SET и DEL. Если ACL команды не режет, пароль кэша открывает и RESTORE. Кто знает этот пароль или кто может открыть сокет без пароля, команду вызвать может. На локальном порту без пароля «уже допущенный клиент» означает любой процесс на этой машине.
CVE-2026-56684 включается только вместе с TLS самого Valkey. Уже допущенный клиент вызывает CLIENT KILL, пока tlsProcessPendingData идёт по списку ожидающих соединений. Соединение закрывается в середине этого прохода, процесс падает или можно запустить чужой код. Баг 1144956. Апстрим закрыл ошибку в 8.1.9. Та же ошибка в Redis числится отдельным номером, CVE-2026-81934. Кэш по обычному TCP на localhost этот код не вызывает.
CVE-2026-82631 в функции handleClientsBlockedOnKey, файл blocked.c: клиенты, которые ждут ключ. В описании атака удалённая, сложность высокая, поймать её трудно, эксплойт уже опубликован. Debian закрыл это в valkey тем же deb13u3. У исходного пакета redis трекер все ветки Debian помечает как vulnerable. Для trixie у redis стоит пометка no-dsa и minor issue. Сегодняшний DSA пакет redis не обновляет.
CVE-2026-82677 в moduleTimerHandler, таймеры загруженного модуля. По описанию процесс можно уронить удалённо, эксплойт опубликован. Без загруженного модуля этот обработчик не вызывается. Обычный object cache модули не грузит. В трекере баг общий с предыдущей карточкой: 1146641. У redis в Debian исправления нет. В заметке к bookworm прямо сказано, что проблема мелкая и нужен загруженный модуль.
Пакет 8.1.1+dfsg1-3+deb13u3
На странице DSA-6586-1 у исходного пакета valkey три строки, которые имеют значение на проде.
- trixie, основной архив:
8.1.1+dfsg1-3+deb13u2, статус vulnerable. - trixie-security:
8.1.1+dfsg1-3+deb13u3, статус fixed. - forky и sid:
9.1.2-1, статус fixed.
Строки bookworm у valkey в этой таблице нет. Сборку deb13u3 на Debian 12 не ставить: это пакет trixie, с зависимостями trixie. На странице Package Tracker есть след старой сборки в stable-backports. Этот бюллетень её не обновляет. На Ubuntu тот же deb тоже не ставится. Там свой пакет и свои USN. Не подмешивать репозиторий trixie в sources.list Ubuntu.
Если apt-cache policy на forky или sid уже показывает 9.1.2-1 или новее, машина получила фикс через testing или unstable. Откатывать её на deb13u3 не нужно. В имени пакета trixie специально остаётся апстрим 8.1.1: Debian кладёт патчи в ревизию, а не поднимает ветку. В заметках трекера коммиты относятся к 8.1.7, 8.1.9 и 8.1.10, в зависимости от карточки. valkey-cli INFO server после обновления может по-прежнему напечатать 8.1.1. Ориентир это строка 8.1.1+dfsg1-3+deb13u3 в dpkg -l.
Часть тех же номеров Debian уже закрывала в пакете redis. На trixie это DSA-6538-1, на bookworm для части карточек DLA-4682-1. CVE-2026-23479 на bookworm у redis помечен как not-affected: уязвимого кода в том пакете нет. CVE-2026-63639 в redis, по заметке трекера, не воспроизводится. Там та же ошибка идёт отдельным номером CVE-2026-66373 и помечена not-affected, потому что неполный фикс CVE-2026-25243 в redis не применяли. Две карточки из сегодняшнего письма, CVE-2026-82631 и CVE-2026-82677, в redis по-прежнему vulnerable. Пакет redict в forky и sid по этим семи CVE трекер тоже ещё помечает как vulnerable. DSA-6586-1 чинит valkey, не redis и не redict.
Рестарт valkey-server на Debian 13
Бинарные пакеты из исходника valkey на странице Debian Package Tracker: valkey-server, valkey-tools, valkey-sentinel. На Debian 13 их и обновляют. Конфиг перед этим править не нужно. Если apt спросит про изменённый файл конфигурации, оставьте свою версию, не подменяйте её файлом из пакета вслепую.
apt-cache policy valkey-server sudo apt update sudo apt install --only-upgrade valkey-server valkey-tools valkey-sentinel dpkg -l 'valkey*' sudo systemctl restart valkey-server
Пост-установочный скрипт пакета часто перезапускает сервис сам. Если systemctl status valkey-server показывает, что процесс живёт с момента до обновления, перезапустите его этой командой. Имя unit другое, его видно в systemctl list-units 'valkey*'. Ребут VPS не нужен: это не ядро и не libc, от которых зависела бы вся машина.
Рестарт стирает данные в памяти. Object cache после этого пустой, первые запросы страниц идут в MariaDB, пока кэш снова не заполнится. Если в Valkey лежат сессии PHP или очередь, рестарт сотрёт и их: пользователей разлогинит, задания в очереди пропадут. nginx здесь перезагружать не из-за чего, пока вы не меняете proxy_pass на этот порт. nginx -t к версии valkey отношения не имеет. PHP-FPM тоже не трогайте: после подъёма порта плагин кэша снова начнёт писать ключи.
Если после apt update policy всё ещё показывает deb13u2, в источниках нет сюита trixie-security. Без него пакет не приедет. Как подключать обновления безопасности, Debian пишет на странице security. На неё же ссылается бюллетень.
На Debian 13, где кэш WordPress работает на Valkey, действие одно: поставить 8.1.1+dfsg1-3+deb13u3 из trixie-security и убедиться, что valkey-server перечитал новый бинарник. Семь карточек не означают семь дыр на каждом таком сервере. TLS самого Valkey, реплика с выключенным replica-read-only, команда RESTORE и загруженный модуль включают разные из них. Закрывает все семь всё равно один пакет.
