В драйвере PostgreSQL для Java, известном как pgjdbc, нашли две уязвимости. Обе ведут к раскрытию информации, но природа у них разная. Первая подмешивает в значения, которые приложение записывает в базу, фрагменты ранее отправленных запросов вместе с их параметрами. Вторая заставляет драйвер принять любой способ аутентификации, если настройка requireAuth запрещает все известные ему методы. Оценки по CVSS средние, 5.3 и 5.9. Исправление появилось 9 октября 2026 года в версии 42.7.14.
Данные прошлых запросов попадают в базу
Первая уязвимость, CVE-2026-107315, живёт в драйвере начиная с 42.7.4 и до 42.7.13 включительно. Срабатывает она на расхождении длин. Приложение объявляет длину значения, а данных передаёт меньше. Драйвер обязан дополнить остаток, и до 42.7.4 он заполнял его нулями. Вместо этого заполнение стало брать содержимое буфера отправки, где лежат тексты недавних запросов и значения их параметров. Сервер сохраняет эти байты как часть значения, поэтому прочитать их может любой, у кого есть доступ к записи.
Разработчики объясняют причину просто. Функция заполнения обнуляла лишь тот участок буфера, который успела перезаписать, а пустой буфер не обнуляла вовсе. Отсюда и утечка.
В буфер попадают не только данные текущего обращения. На пуле соединений он хранит фрагменты запросов, которые отправил другой клиент или другой пользователь. Поэтому в запись уходит до 8192 байт чужого трафика, а на соединении с шифрованием GSS (обмен ключами через Kerberos) - до 16320 байт.
Хватает совсем небольшого расхождения. Если данные заканчиваются ровно на границе буфера, дополнение заполняется параметрами того же запроса и предыдущими строками той же пакетной вставки. Промах в один байт ещё даёт нули. Попадание в границу уже нет.
Дополнить значение драйвер позволяет через несколько точек входа. Среди них подготовленные выражения с потоковой записью данных, массовая загрузка COPY, работа с большими объектами и запись в BLOB. Ошибку в вызове драйвер при этом не выдаёт. Приложения, у которых объявленная длина всегда совпадает с объёмом переданных данных, не затронуты. Версии 42.7.3 и старше заполняют буфер нулями. Но значения, записанные уязвимой версией, уже могут содержать чужие данные.
Настройка requireAuth пропускает любой метод
Вторая уязвимость, CVE-2026-107314, появилась в 42.7.11 и держалась до 42.7.13. Настройка requireAuth перечисляет способы аутентификации, которые драйвер готов принять. Если перечислить все шесть известных методов с отрицанием, драйвер обязан запретить всё. На практике он не ограничивает ничего. Причина в том, что отсутствие настройки и её пустое значение драйвер трактовал одинаково.
Дальше срабатывает атака "человек посередине". Злоумышленник, оказавшийся между приложением и сервером, запрашивает проверку паролем открытым текстом. Драйвер соглашается, и пароль базы уходит атакующему.
Частичный запрет работает правильно. Значение вида requireAuth=!password,!md5 драйвер исполняет, положительный список вроде requireAuth=scram-sha-256 тоже. Своё значение по умолчанию у настройки отсутствует, поэтому развёртывания, которые её не задают, не затронуты. Запрет всех методов никто не выставляет намеренно. Такое значение появляется по ошибке, а на уязвимых версиях соединения продолжают работать и маскируют её. Именно на эту настройку полагаются организации, которые ходят в PostgreSQL из Java-приложений и хотят ограничить способы входа.
Обновление до 42.7.14 и проверка настроек
Версия 42.7.14 закрывает обе уязвимости. После обновления соединение, где requireAuth исключает все методы, отклоняется с кодом SQLState 08004. Значение без единого метода драйвер считает недопустимым. Замените его положительным списком способов, которые использует сервер, например requireAuth=scram-sha-256. Для SCRAM поверх TLS подойдёт channelBinding=require, при md5, GSS или SSPI он не сработает. Независимо от этой истории проверьте сертификат сервера через sslmode=verify-full и доверенный удостоверяющий центр. Записи, созданные уязвимой версией, придётся найти и перезаписать.
Обе проблемы требуют нетипичных условий. Приложение должно ошибиться в длине значения, а администратор - выставить бессмысленную настройку аутентификации. Редкость условий не отменяет последствий. Один запрос способен вынести в базу пароль, другой - чужие данные из пула соединений, и заметить это по журналам непросто.
Ссылки
- https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-f64h-wr5q-3qf3
- https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-rhp9-mr79-r74h
- https://www.cve.org/CVERecord?id=CVE-2026-107314
- https://www.cve.org/CVERecord?id=CVE-2026-107315
- https://www.postgresql.org/about/news/2026-10-07-postgresql-jdbc-42714-security-update-for-multiple-cves-3399/
