Панель управления pgAdmin 4 в версиях с 6.2 по 9.17 пропускает в систему любого, кто назовёт себя чужим именем в обычном HTTP-заголовке. Злоумышленник входит под чужой учётной записью, включая администраторскую, без пароля, без второго фактора и без других учётных данных. Ошибка получила идентификатор CVE-2026-86863, оценка по CVSS 3.1 (система оценки серьёзности уязвимостей) составляет 9.8 из 10. Под угрозой установки, где включён режим аутентификации webserver. В нём проверку пользователя выполняет внешний веб-сервер, а pgAdmin принимает готовый результат.
Уязвимость CVE-2026-86863
pgAdmin - распространённый инструмент администрирования PostgreSQL. Через него настраивают базы, правят данные, управляют ролями и правами. Прямой доступ к нему обычно закрыт, а на входе ставят обратный прокси. Прокси проверяет пользователя и передаёт его имя приложению через переменную окружения CGI или WSGI (способы связи веб-сервера с приложением на Python). Схема удобна: аутентификация собрана в одном месте, а панель ей доверяет.
Ошибка в том, как pgAdmin читал это имя. Сначала приложение обращалось к окружению запроса. Если нужного значения там не оказывалось, код брал значение с тем же именем из входящего HTTP-заголовка. Заголовок формирует отправитель запроса. Значит, любой клиент, дотянувшийся до панели, мог сам подставить имя пользователя и получить сессию от его лица. Пароль, второй фактор и прочие проверки в этой цепочке не участвуют.
Риск возрастает при определённой настройке. Если администратор задавал имя переменной с префиксом HTTP_ или через дефис, сервер WSGI помещал клиентский заголовок в окружение под тем же именем. Тогда подстановка срабатывала ещё до запасного варианта с чтением заголовков напрямую. Иными словами, доверие к внешнему серверу превращалось в доверие к любому, кто отправил запрос.
Промах в правах доступа обходится дорого. Сессия администратора pgAdmin открывает объекты баз данных и сами данные. Их можно просмотреть, изменить или удалить. Иногда через панель доступны настройки серверов и учётные записи к ним, а это уже доступ к самим системам управления базами данных. Одна такая сессия способна пережить сам инцидент: следов подлога в приложении не остаётся.
По CVSS 4.0 (обновлённая версия той же методики) уязвимость оценили в 9.3. Вектор описывает атаку по сети с низкой сложностью, без привилегий и без участия пользователя. Влияние на конфиденциальность, целостность и доступность признано высоким по всем трём составляющим. Подготовка не нужна: всё, что требуется от атакующего, - сетевой доступ к панели и знание имени нужной учётной записи.
Область применения ограничена. Уязвимость работает только там, где в списке источников аутентификации включён webserver. Организации, которые входят через внутреннюю базу пользователей, каталог LDAP или иные механизмы, этой ошибке не подвержены. Данных о применении уязвимости в реальных атаках нет. Нашёл её исследователь Санхён Ли (Sanghyeon Lee), известный под псевдонимом h9e0n. Диапазон затронутых выпусков широкий - от 6.2 до 9.17, поэтому неприятность может ждать и в установках, которые годами не трогали.
Исправление вышло в версии 9.18. Код теперь различает значение, которое передал сервер, и значение, пришедшее из заголовка, и по умолчанию доверяет только первому. Доверие к заголовку включается отдельной настройкой. Условий два: запрос должен прийти с адреса доверенного прокси, а при желании администратор добавляет общий секрет, который стороны сверяют при каждом запросе.
Проверку адреса разработчики переписали на чтение реального адреса соединения. Раньше код полагался на значение, которое прокси подставляет из заголовка о цепочке пересылки, и это значение подделывает отправитель. Теперь злоумышленник не может выдать себя за доверенный прокси. Дополнительно вход через webserver закрыли для учётных записей с другим источником аутентификации. Такая мера не даёт ошибке в настройке доверия превратиться в доступ к внутренней или каталоговой учётной записи.
Что делать администраторам. Обновиться до версии 9.18 или более позднего выпуска, причём сразу: обход аутентификации не требует ни подготовки, ни особых условий. Затем пересмотреть настройки обратного прокси. Заголовки с именем пользователя должны приниматься только от доверенных адресов, а сам прокси обязан закрывать доступ к панели снаружи.
В журналах имеет смысл поискать необычные сессии, входы администраторов и подозрительные значения заголовков. Полезно проверить, не появились ли в базах новые учётные записи и не менялись ли права ролей. Следов подмены при этом может не остаться, поскольку приложение считало такой вход законным. Поэтому журналы обратного прокси дадут больше, чем логи самой панели.
Схема с доверием к внешнему серверу встречается в десятках продуктов: так работают панели администрирования, системы мониторинга, внутренние порталы. Пока приложение отличает переменную окружения от заголовка, схема безопасна. Как только эти два источника путают, внешний периметр теряет смысл, и защита от неавторизованного доступа превращается в формальность. Панели управления базами данных ценны для злоумышленников: одна сессия даёт доступ ко всем данным организации.
Ссылки
