Критическая уязвимость в ProxySQL: удалённая атака без аутентификации грозит компрометацией баз данных

В Банк данных угроз безопасности информации (BDU) была внесена запись о новой опасной уязвимости, затрагивающей популярный прокси-сервер для баз данных ProxySQL. Речь идёт об ошибке, которая позволяет злоумышленнику, действующему удалённо, полностью обойти механизмы защиты и получить доступ на чтение и изменение данных, хранящихся за этим балансировщиком. Оценка по шкале CVSS 3.1 достигла максимальных 10 баллов, что говорит о высочайшем уровне угрозы.

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

ProxySQL - это программный продукт, который широко используется для балансировки нагрузки и маршрутизации запросов к базам данных, в первую очередь MySQL и MariaDB. Он выполняет роль посредника между клиентскими приложениями и серверами хранения данных, оптимизируя соединения и повышая отказоустойчивость инфраструктуры. Уязвимость получила идентификаторы BDU:2026-08519 и CVE-2026-48772 и затрагивает все версии продукта от 2.0.0 до 3.0.9 включительно.

Разработчики ProxySQL реализовали механизм обновлений, полагаясь на ненадёжный источник данных. Иными словами, при загрузке обновлений и конфигурационной информации прокси-сервер не проверяет подлинность источника, что открывает путь для подмены данных. Злоумышленник, перехватив поток передачи, может внедрить вредоносную полезную нагрузку или изменить настройки. Это классический пример ошибки CWE-348, которая описывает использование менее надежного источника.

Найденная проблема также классифицируется как неправильная обработка выходных данных для журналов регистрации (CWE-117) и неверная авторизация (CWE-863). Первая из этих ошибок позволяет скрыть следы атаки, повредив логи. Вторая, более опасная, даёт возможность злоумышленнику выполнять операции без надлежащей проверки прав доступа. В совокупности эти три дефекта превращают атаку на ProxySQL в почти идеальный сценарий: нарушитель может не только украсть данные, но и замести следы.

Особую тревогу вызывает способ эксплуатации. Вектор атаки по сети (AV:N) и низкая сложность (AC:L) означают, что для проведения атаки не требуется физического доступа к серверу. Аутентификация также не нужна (PR:N), поэтому атаковать может любой, кто имеет доступ к сети, где работает прокси-сервер. В открытом доступе уже существует эксплойт, то есть готовый код для проведения атаки. Это резко повышает вероятность массовых атак.

На практике эксплуатация может выглядеть так: нарушитель отправляет специально сформированные пакеты данных, которые ProxySQL принимает как легитимные обновления. В результате сервер загружает изменённую конфигурацию или код, что позволяет злоумышленнику управлять маршрутизацией запросов к базам данных. Более того, атакующий может перехватывать и изменять данные на лету, что создаёт угрозу для целостности информации.

Последствия успешной атаки могут быть катастрофическими. Компании, которые используют ProxySQL в качестве центрального элемента своей базы данных, рискуют потерять конфиденциальные данные клиентов, финансовую отчётность или служебную информацию. Поскольку атака не затрагивает только конфиденциальность, но и целостность данных (вектор включает C/C для CVSS 3.1), злоумышленник может незаметно вносить изменения, которые приведут к ошибочным транзакциям или сбоям в работе приложений.

Разработчики из ProxySQL Ltd. уже выпустили обновление версии 3.0.9, в котором уязвимость устранена. На странице проекта на GitHub опубликованы рекомендации и патч. Специалистам по информационной безопасности настоятельно рекомендуется как можно скорее обновить прокси-сервер до последней версии. Учитывая наличие публичного эксплойта, каждый час промедления увеличивает риск атаки.

Какие меры можно предпринять прямо сейчас? Прежде всего необходимо проверить версию установленного ProxySQL. Если она попадает в диапазон от 2.0.0 до 3.0.9, обновление обязательно. Для систем с ограниченным доступом к сети обновление может быть выполнено из изолированного репозитория. Кроме того, стоит усилить мониторинг входящих подключений и проверять логи на предмет необычных запросов.

В целом этот инцидент напоминает о том, что даже зрелые и широко используемые проекты могут содержать опасные ошибки. Полагаться только на базовую защиту сети - недостаточно. Необходимо регулярно актуализировать информацию о вновь выявляемых уязвимостях в BDU и оперативно реагировать на предупреждения вендоров. Установка патча - единственный надёжный способ защиты от данной угрозы.

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

Ссылки