Пятнадцать уязвимостей MariaDB: что обновить и кого это касается

9 и 16 октября 2026 года в базе NVD опубликовали пятнадцать уязвимостей MariaDB. Четыре из них с оценкой 9,9 из 10, ещё четыре — от 8,0. Все закрыты в версиях 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3 и 13.0.2.

Разбираем, что нашли, почему страшные оценки здесь означают не то, что обычно, и как понять, касается ли это вашего сервера.

Главное за минуту

• Пятнадцать уязвимостей, четыре с оценкой 9,9. Исправлены в 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3 и 13.0.2.
• Ни одна не эксплуатируется снаружи без доступа к базе: всем нужен хоть какой-то аккаунт в СУБД.
• Это не повод отложить обновление. Такие дыры превращают обычную SQL-инъекцию в сайте в выполнение кода на сервере.
• На типовой BitrixVM вас это не касается: там MySQL или Percona Server. MariaDB — это хостинги с панелями, Debian и Ubuntu, старые сборки.
• Ветка 10.6 вышла из поддержки сообщества 6 июля 2026 года. Обновиться до 10.6.28 можно, но дальше патчей не будет — надо переходить на 10.11 или 11.4.

Почему «девять и девять» здесь не значит «придут снаружи»

Оценка CVSS описывает худший исход, а не вероятность. Чтобы понять, грозит ли уязвимость конкретному серверу, смотреть надо не на цифру, а на вектор — строку условий рядом с ней.

У всех пятнадцати октябрьских записей в векторе стоит PR:L или PR:H — требуются привилегии: низкие или высокие. То есть атакующему нужен действующий аккаунт в базе. Анонимный запрос из интернета в порт 3306 ничего из этого не запускает. Как читать вектор целиком и за что в нём цепляться, мы разобрали в отдельном материале.

Из этого обычно делают вывод: база наружу не смотрит, значит можно не спешить. Спешить стоит, и вот почему.

Аккаунт в базе есть у самого сайта — он лежит в dbconn.php или в .env. Если в коде найдётся SQL-инъекция, атакующий получает те же права, с которыми ходит сайт. Дальше разница вот в чём: без этих уязвимостей он читает и меняет данные в одной базе, с ними — выходит за пределы СУБД и выполняет код на сервере. Одна дыра среднего размера в приложении превращается в полный захват машины.

Второй сценарий — общий хостинг. Там соседи по серверу тоже имеют аккаунты в той же СУБД, и чужая база становится дорогой к вашей.

Что именно нашли

Обход кодирования имён таблиц

CVE-2026-92262, оценка 9,9. MariaDB хранит таблицы файлами и кодирует имена, чтобы в имя файла не попало лишнее. Префикс #mysql50#, оставшийся для совместимости со старыми базами, это кодирование отключает. Пользователь с минимальными правами создаёт таблицу с таким именем и обращается к файлам под их настоящими именами. В описании прямо перечислены последствия: падение сервера, порча данных, утечка и выполнение кода.

Выход за буфер в geometry-функциях

CVE-2026-85746, оценка 9,9. Функция ST_AsText при переводе вложенных объектов GeometryCollection в текст пишет за границу выделенного буфера: рекурсия не считает израсходованные байты. Достаточно одного подготовленного GIS-объекта. Сама по себе она портит память, а в связке с другой уязвимостью доводит до выполнения кода.

Рядом CVE-2026-85745 с оценкой 4,3 — та же история в ST_Area, но с чтением за границей.

Чужой пароль через GRANT PROXY

CVE-2026-97380, оценка 8,8. Команда GRANT PROXY с пустым паролем в конструкции IDENTIFIED обрабатывается так, будто аутентификация не указана вовсе, и права проверяются не у того, у кого надо. Итог: пользователь с низкими правами задаёт пароль другому аккаунту, если знает его имя. Имена аккаунтов — не секрет.

Отравленный дамп

CVE-2026-86047, оценка 7,7. SHOW CREATE SERVER, SHOW CREATE USER и mariadb-dump непоследовательно экранируют идентификаторы и значения. Атакующий создаёт объект с таким именем, что в выгрузке получается готовая SQL-команда. Она ничего не делает, пока лежит в файле, и срабатывает при восстановлении дампа — обычно под полными правами администратора.

Это тот случай, когда резервная копия работает против вас: вы восстанавливаетесь после инцидента и сами же выполняете то, что подложили заранее.

Домашний каталог служебного пользователя

CVE-2026-107814, оценка 8,4. В RPM-пакетах — а это AlmaLinux, Rocky, RHEL и CentOS — служебный аккаунт mysql создавался с домашним каталогом, совпадающим с каталогом данных базы. Пользователь с правом FILE записывает туда .bash_profile, и файл выполняется, когда администратор заходит в систему под этим аккаунтом. В пакетах Debian и Ubuntu этого нет: там домашним каталогом назначен несуществующий путь.

Подмена окружения при перезапуске

CVE-2026-107818, оценка 8,4. Unit systemd читал файл /run/mysqld/wsrep-new-cluster при следующем старте сервиса. Если secure-file-priv разрешает запись в этот каталог, пользователь с правом FILE создаёт файл и подсовывает свои переменные окружения в перезапущенный сервис.

Движок CONNECT

CVE-2026-107815, оценка 8,5, и CVE-2026-85985 — в движке CONNECT. Он не включён по умолчанию, и если вы не знаете, что это такое, у вас его нет.

Что ещё лежит в этой же корзине

Монитор, который мы держим на своём сервере, вытащил вместе с октябрьскими и июньские записи MariaDB — им в октябре переписали оценки, и в ленте они выглядят как свежие. Разницу стоит держать в голове: по июньским исправления вышли ещё летом, в 10.6.27, 10.11.18, 11.4.12 и 11.8.8.

Из июньской серии практический интерес представляют две.

CVE-2026-49261, оценка 10,0. Параметр wsrep_notify_cmd выполнял команды оболочки, попавшие в имя присоединяющегося узла. Это кластер Galera — для одиночного сервера неприменимо.

CVE-2026-44172, оценка 9,1. Коннектор версий 3.3.18 и 3.4.8: приложение экранировало пользовательский ввод через mysql_real_escape_string() и всё равно получало SQL-инъекцию — при кодировке big5 и текстовом протоколе. Исправлено в 3.3.19 и 3.4.9. PHP на Linux обычно собран с mysqlnd и этот коннектор не использует, так что к сайтам на Битриксе это отношения не имеет.

У кого вообще MariaDB

Прежде чем обновлять, проверьте, что обновлять есть что. MariaDB и MySQL — разные продукты, и уязвимости у них свои.

• BitrixVM ставит MySQL или Percona Server. Октябрьской волны там нет.
• Хостинг с панелью — ISPmanager, cPanel, Plesk — чаще всего MariaDB.
• Debian и Ubuntu: пакет mysql-server в Debian ставит именно MariaDB.
• Старые сборки на CentOS 7 — чаще MariaDB 5.5 или 10.x, и там отдельный разговор про поддержку.

Как проверить свою версию

Из консоли сервера:

mysql --version
# или
mysqld --version

Если в выводе есть слово MariaDB — продукт тот. Если написано MySQL или Percona Server — эта статья не про ваш сервер.

Если доступа к консоли нет, номер версии покажет сама база:

SELECT VERSION();

Запрос выполняется в phpMyAdmin или в консоли панели управления. В Битриксе то же самое видно в административной части, в разделе проверки системы.

Дальше сверяйте с исправленными версиями: 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, 13.0.2. Всё, что ниже внутри своей ветки, уязвимо.

Как обновить

Обновление внутри ветки — операция рутинная: меняется третья цифра, формат данных не трогается. Но база живёт на сервере не одна, поэтому порядок такой.

1. Снимите дамп и проверьте, что он читается. Не «сделайте бэкап», а именно проверьте: в инциденты попадают те, у кого копия была, но не разворачивалась.
2. Посмотрите, что ещё зависит от пакета. На сервере с панелью управления обновление СУБД часто тянет за собой перезапуск веб-сервера.
3. Обновите пакеты. На AlmaLinux, Rocky и RHEL:

   dnf clean all && dnf update MariaDB-server MariaDB-client
   systemctl restart mariadb

   На Debian и Ubuntu:

   apt update && apt install --only-upgrade mariadb-server mariadb-client
   systemctl restart mariadb

4. Выполните mariadb-upgrade, если он не отработал сам: команда приводит системные таблицы в соответствие с новой версией.
5. Проверьте, что сайт открывается, и что в журнале базы нет ошибок после старта.

На сервере с панелью управления обновляйте через саму панель, а не через консоль. Иначе панель продолжит считать установленной старую версию и в следующий раз откатит её обратно своим обновлением.

Если у вас ветка 10.6

Поддержка сообщества для 10.6 закончилась 6 июля 2026 года. Октябрьские исправления для неё выпустили, 10.6.28 существует — но следующей порции может уже не быть.

Это значит, что обновление до 10.6.28 закрывает сегодняшнюю проблему и не решает завтрашнюю. Планируйте переход на ветку с поддержкой: 10.11 — до 16 февраля 2028 года, 11.4 — до 29 мая 2029 года. Переход между ветками уже не рутина: меняется поведение оптимизатора, иногда ломаются запросы, которые работали годами. Делать его надо на копии, с прогоном нагрузки.

Если сервер не ваш

На общем хостинге версию СУБД выбираете не вы. Что можно сделать:

• Посмотрите версию запросом SELECT VERSION() и напишите в поддержку: укажите номера CVE и спросите, когда планируется обновление. Формулировка с конкретными идентификаторами работает лучше, чем «у вас дыра».
• Если ответа нет или сроки неопределённые — это аргумент в пользу переезда на собственный сервер, где решение принимаете вы.
• Независимо от хостера закройте то, что в вашей власти: проверьте код на SQL-инъекции и уберите у аккаунта базы лишние права. Право FILE, через которое работают две уязвимости из списка, обычному сайту не нужно вообще.

SHOW GRANTS FOR CURRENT_USER();

Если в выводе видно FILE или ALL PRIVILEGES на уровне *.*, права стоит урезать до нужной базы.

Что мы делаем у клиентов на поддержке

Ленту NVD и каталог активно эксплуатируемых уязвимостей CISA мы просматриваем ежедневно — автоматически, по списку того, что обслуживаем: PHP, базы, веб-серверы, платформа. Когда появляется что-то серьёзное, смотрим, у кого из клиентов это стоит, и обновляем. Если у вас нет такой проверки, её стоит завести — в любом виде, хоть вручную раз в неделю.

Источники

• CVE-2026-92262, CVE-2026-85746, CVE-2026-97380, CVE-2026-86047 — описания в NVD.
• CVE-2026-107814 и CVE-2026-107818 — ошибки в пакетах и unit-файле.
• endoflife.date — сроки поддержки веток MariaDB.
• База знаний MariaDB — списки исправленных уязвимостей по версиям.

Если не уверены, что стоит на вашем сервере и нужно ли его обновлять, — напишите нам: посмотрим конфигурацию, проверим версии и обновим без простоя.