Механизм уведомлений о состоянии кластера в MariaDB допускает удалённое внедрение команд

В системе управления базами данных MariaDB обнаружена уязвимость, позволяющая выполнить произвольные команды на сервере. Она затрагивает механизм, который уведомляет о смене состояния кластера. Этот механизм передаёт сведения об узлах во внешнюю команду операционной системы. Однако специальные символы в передаваемых значениях не нейтрализуются. Поэтому злоумышленник может дописать к команде собственные инструкции. Базовая оценка по CVSS 3.1 составляет 10 баллов из 10, то есть максимум по этой шкале.

Детали уязвимости

Эксплуатация не требует учётных данных и действий со стороны пользователя. Атака проводится по сети, причём метрика смены области действия указывает на выход за пределы самой СУБД. По классификации CWE-78 ошибка отнесена к внедрению в команду операционной системы. В Банке данных угроз безопасности информации уязвимость зарегистрирована под номером BDU:2026-14967, в международном реестре ей присвоен идентификатор CVE-2026-49261. Статус подтверждён производителем, значит речь идёт не о теоретической находке, а о подтверждённой бреши в коде продукта.

Под удар попадают несколько веток MariaDB. Речь идёт о версиях с 10.6.1 по 10.6.27, с 10.11.1 по 10.11.18, с 11.4.1 по 11.4.12, с 11.8.1 по 11.8.8, а также о сборке 12.3.1. Проблема не ограничивается самой СУБД, поскольку пакеты MariaDB входят в состав популярных операционных систем. Среди затронутых платформ Red Hat Enterprise Linux 8, 9 и 10 вместе с каналами расширенной поддержки, Debian GNU/Linux 12 и 13, Ubuntu 26.04 LTS, РЕД ОС 7.3 и 8.0, а также Red Hat Hardened Images. Следовательно, под угрозой оказываются и те организации, которые используют MariaDB как часть инфраструктурного дистрибутива, а не как отдельно установленный продукт.

Ключевая особенность этой уязвимости в том, что она связана с кластерным режимом работы. Механизм уведомлений нужен там, где база данных распределена между несколькими узлами и они должны согласованно реагировать на изменение состава кластера. Обычно такая схема встречается в отказоустойчивых инсталляциях, где от стабильности базы зависит работа прикладных систем. Если настройка уведомлений не применяется, поверхность атаки заметно уже. Тем не менее проверка конфигурации уместна для всех, кто работает с перечисленными версиями.

Отдельного внимания заслуживает характер доступа, который получает атакующий. Выполнение произвольных команд в контексте службы базы данных означает доступ к файлам, к сетевым подключениям и к учётным данным, которые обрабатывает сервер. Кроме того, злоумышленник может закрепиться в системе и использовать compromised-узел как плацдарм для дальнейшего продвижения по внутренней сети. Такой сценарий особенно чувствителен для промышленных и финансовых организаций, где база данных обслуживает критичные процессы.

Исправления уже выпущены. Уязвимость закрыта в MariaDB, а также в дистрибутивах, куда вошли исправленные пакеты. Компания Red Hat опубликовала серию уведомлений об обновлениях, аналогичные материалы подготовили сопровождающие Debian и Ubuntu. Для РЕД ОС обновлённые пакеты размещены в репозиториях "repo.red-soft.ru/redos/8.0/x86_64/updates/" и "repo.red-soft.ru/redos/7.3c/x86_64/updates/". Администраторам следует обновить MariaDB до версий новее перечисленных границ и перезапустить службу, чтобы изменения вступили в силу.

Если обновление по каким-то причинам недоступно, разумно опираться на "Рекомендации по безопасной настройке операционных систем LINUX", утверждённые ФСТЭК России 25 декабря 2022 года. Этот документ описывает базовые меры ограничения прав служб, изоляцию сетевых сегментов и контроль запускаемых процессов. Дополнительно стоит проверить, задана ли в конфигурации команда уведомления о состоянии кластера, и при отсутствии необходимости в ней отказаться от такого параметра. Ограничение сетевого доступа к портам СУБД тоже снижает риск: уязвимость эксплуатируется удалённо, поэтому фильтрация трафика напрямую уменьшает число точек входа.

История с MariaDB продолжает серию проблем в компонентах, которые редко оказываются на первом плане внимания администраторов. Кластерная логика, фоновые задачи, служебные уведомления - всё это исполняется с высокими правами и часто остаётся вне регулярного аудита. При этом именно такие участки дают атакующему максимальный результат при минимальных требованиях к доступу. Последовательное обновление баз данных, ревизия конфигураций и контроль исходящих соединений от серверов СУБД остаются базовыми мерами, которые работают и против подобных уязвимостей.

Детали уязвимости

Ссылки