12 августа 2026 года в 10:46 UTC исследователь @q1uf3ng сообщил в X о несанкционированной SQL-инъекции в функции jsonArrayContains открытой платформы GeoServer. Его формулировка была прямой: «Несанкционированная SQL-инъекция в GeoServer jsonArrayContains, а при использовании базы данных с учётной записью системного администратора вполне возможно добиться удалённого выполнения кода». На момент публикации исправления и номера CVE не существовало, поэтому уязвимость считалась нулевым днём. Позднее ей присвоили идентификатор GitHub Security Advisory GHSA-mqjf-5f49-2fjh и оценку 9,8 из 10 по CVSS.
Платформа разведки угроз и управления внешней поверхностью атаки watchTowr заметила вредоносную активность уже через несколько часов после раскрытия. С небольшого пула IP-адресов поступили сотни запросов к доступным из интернета экземплярам GeoServer. Пока операторы в основном искали уязвимые серверы и отправляли пробы, вызывавшие ошибки, но не переходили к следующим стадиям атаки. Главный исследователь безопасности watchTowr Jake Knott рассказал изданию The Hacker News: «Сейчас мы видим, как злоумышленники зондируют интернет в поисках уязвимых систем, вызывают ошибки и не продвигаются дальше».
Спокойным это наблюдение не делает. По оценке Jake Knott, стадия разведки вряд ли затянется: уязвимости GeoServer уже использовались в массовых кампаниях, а несколько из них внесены Агентством по кибербезопасности и защите инфраструктуры США в каталог известных эксплуатируемых уязвимостей CISA KEV. Новый дефект при определённой конфигурации позволяет превратить SQL-инъекцию в удалённое выполнение кода, или RCE. То есть короткая ошибочная проба в журнале может оказаться проверкой перед более содержательной атакой.
Уязвимый путь возникает при обработке фильтров Open Geospatial Consortium (OGC) через реализацию PostGIS DataStore. Для эксплуатации нужны PostGIS 12 или новее и поле типа String либо JSON. Разработчики GeoServer описали проблему так: «SQL-инъекция обнаружена при выполнении OGC-фильтров с реализацией PostGIS DataStore: функция jsonArrayContains». В конструкции jsonArrayContains(<column>, <pointer>, <value>) управляемое извне значение <value> попадает в создаваемый SQL без правильного экранирования.
Сам дефект находится в библиотеке GeoTools, в компоненте geotools:gt-jdbc-postgis, который переводит фильтры Common или Contextual Query Language (CQL) в SQL-запросы для хранилищ на базе PostGIS. Полученное из HTTP-запроса значение напрямую вставляется в SQL-литерал PostgreSQL внутри выражения jsonb_path_exists(): очистки и экранирования перед вставкой нет. Дополнительные технические сведения опубликовал Hadrian. Исследователь безопасности Melvin Lammerts сформулировал причину кратко: «Контролируемое атакующим значение напрямую подставляется в выражение PostgreSQL jsonb_path_exists() без экранирования».
Путь к выполнению команд операционной системы связан с Web Feature Service (WFS) 1.0. Этот вариант запроса допускает выполнение второго оператора PostgreSQL на верхнем уровне. Если GeoServer подключён к базе от имени суперпользователя PostgreSQL либо роли с привилегией pg_execute_server_program, инъекцию можно развить до запуска команд на сервере базы данных. «Если GeoServer подключается к PostgreSQL с помощью суперпользователя или роли с pg_execute_server_program, это приводит к выполнению команд ОС на узле базы данных», — пояснил Melvin Lammerts.
Обычная учётная запись PostgreSQL ограничивает последствия, но не закрывает уязвимость. Без статуса суперпользователя и права pg_execute_server_program атакующий всё ещё способен читать или изменять данные в пределах разрешений пользователя базы. По словам Lammerts, «без этих повышенных привилегий PostgreSQL SQL-инъекция всё равно работает и может применяться для доступа к данным, доступным пользователю базы данных». Поэтому проверять требуется не только признаки запуска системных команд: подозрительные выборки, обращения к нетипичным таблицам и ошибки SQL тоже могут указывать на эксплуатацию.
Исправления вошли в GeoServer 3.0.1, 2.28.5 и 2.27.6. Для пакета geotools:gt-jdbc-postgis ветка GeoTools 35.0 исправлена в версии 35.1, выпуски 34.0 и новее в ветке 34.x — в 34.5, а версии начиная с 33.1 в ветке 33.x — в 33.6. Владелец проекта GeoCat Jody Garnett, к которому за комментарием обратилось The Hacker News, подтвердил, что речь идёт об известной проблеме библиотеки GeoTools и что она устранена во всех трёх выпусках GeoServer.
Разработчики назвали GHSA-mqjf-5f49-2fjh регрессией CVE-2023-25158 — другой критической SQL-инъекции с оценкой CVSS 9,8, исправленной в феврале 2023 года вместе с CVE-2023-25157. История повторяется не впервые. В 2024 году уязвимость GeoServer GeoTools CVE-2024-36401, также получившая 9,8 балла, активно применялась для захвата серверов. Скомпрометированные узлы включали в DDoS-ботнеты, ботнеты для добычи криптовалюты и сети резидентских прокси. Именно такой опыт стоит за предупреждением watchTowr о вероятности массовой эксплуатации нового дефекта.
Администраторам следует немедленно найти все доступные из интернета экземпляры GeoServer и обновить их до 3.0.1, 2.28.5 либо 2.27.6, одновременно проверив установку GeoTools 35.1, 34.5 или 33.6 для соответствующей ветки. Публичный доступ лучше ограничить сетевыми правилами, а соединение GeoServer с PostgreSQL перевести с суперпользователя и ролей, обладающих pg_execute_server_program, на отдельную минимально привилегированную учётную запись. В журналах нужно искать массовые пробы, ошибки SQL, необычные запросы WFS 1.0, обращения к jsonArrayContains, признаки доступа к данным и запуск команд на узле базы. До выхода патчей рекомендовалось следить за обновлениями поставщика; теперь ожидание лишь оставляет уже известную точку входа открытой.
Изображение носит иллюстративный характер
Платформа разведки угроз и управления внешней поверхностью атаки watchTowr заметила вредоносную активность уже через несколько часов после раскрытия. С небольшого пула IP-адресов поступили сотни запросов к доступным из интернета экземплярам GeoServer. Пока операторы в основном искали уязвимые серверы и отправляли пробы, вызывавшие ошибки, но не переходили к следующим стадиям атаки. Главный исследователь безопасности watchTowr Jake Knott рассказал изданию The Hacker News: «Сейчас мы видим, как злоумышленники зондируют интернет в поисках уязвимых систем, вызывают ошибки и не продвигаются дальше».
Спокойным это наблюдение не делает. По оценке Jake Knott, стадия разведки вряд ли затянется: уязвимости GeoServer уже использовались в массовых кампаниях, а несколько из них внесены Агентством по кибербезопасности и защите инфраструктуры США в каталог известных эксплуатируемых уязвимостей CISA KEV. Новый дефект при определённой конфигурации позволяет превратить SQL-инъекцию в удалённое выполнение кода, или RCE. То есть короткая ошибочная проба в журнале может оказаться проверкой перед более содержательной атакой.
Уязвимый путь возникает при обработке фильтров Open Geospatial Consortium (OGC) через реализацию PostGIS DataStore. Для эксплуатации нужны PostGIS 12 или новее и поле типа String либо JSON. Разработчики GeoServer описали проблему так: «SQL-инъекция обнаружена при выполнении OGC-фильтров с реализацией PostGIS DataStore: функция jsonArrayContains». В конструкции jsonArrayContains(<column>, <pointer>, <value>) управляемое извне значение <value> попадает в создаваемый SQL без правильного экранирования.
Сам дефект находится в библиотеке GeoTools, в компоненте geotools:gt-jdbc-postgis, который переводит фильтры Common или Contextual Query Language (CQL) в SQL-запросы для хранилищ на базе PostGIS. Полученное из HTTP-запроса значение напрямую вставляется в SQL-литерал PostgreSQL внутри выражения jsonb_path_exists(): очистки и экранирования перед вставкой нет. Дополнительные технические сведения опубликовал Hadrian. Исследователь безопасности Melvin Lammerts сформулировал причину кратко: «Контролируемое атакующим значение напрямую подставляется в выражение PostgreSQL jsonb_path_exists() без экранирования».
Путь к выполнению команд операционной системы связан с Web Feature Service (WFS) 1.0. Этот вариант запроса допускает выполнение второго оператора PostgreSQL на верхнем уровне. Если GeoServer подключён к базе от имени суперпользователя PostgreSQL либо роли с привилегией pg_execute_server_program, инъекцию можно развить до запуска команд на сервере базы данных. «Если GeoServer подключается к PostgreSQL с помощью суперпользователя или роли с pg_execute_server_program, это приводит к выполнению команд ОС на узле базы данных», — пояснил Melvin Lammerts.
Обычная учётная запись PostgreSQL ограничивает последствия, но не закрывает уязвимость. Без статуса суперпользователя и права pg_execute_server_program атакующий всё ещё способен читать или изменять данные в пределах разрешений пользователя базы. По словам Lammerts, «без этих повышенных привилегий PostgreSQL SQL-инъекция всё равно работает и может применяться для доступа к данным, доступным пользователю базы данных». Поэтому проверять требуется не только признаки запуска системных команд: подозрительные выборки, обращения к нетипичным таблицам и ошибки SQL тоже могут указывать на эксплуатацию.
Исправления вошли в GeoServer 3.0.1, 2.28.5 и 2.27.6. Для пакета geotools:gt-jdbc-postgis ветка GeoTools 35.0 исправлена в версии 35.1, выпуски 34.0 и новее в ветке 34.x — в 34.5, а версии начиная с 33.1 в ветке 33.x — в 33.6. Владелец проекта GeoCat Jody Garnett, к которому за комментарием обратилось The Hacker News, подтвердил, что речь идёт об известной проблеме библиотеки GeoTools и что она устранена во всех трёх выпусках GeoServer.
Разработчики назвали GHSA-mqjf-5f49-2fjh регрессией CVE-2023-25158 — другой критической SQL-инъекции с оценкой CVSS 9,8, исправленной в феврале 2023 года вместе с CVE-2023-25157. История повторяется не впервые. В 2024 году уязвимость GeoServer GeoTools CVE-2024-36401, также получившая 9,8 балла, активно применялась для захвата серверов. Скомпрометированные узлы включали в DDoS-ботнеты, ботнеты для добычи криптовалюты и сети резидентских прокси. Именно такой опыт стоит за предупреждением watchTowr о вероятности массовой эксплуатации нового дефекта.
Администраторам следует немедленно найти все доступные из интернета экземпляры GeoServer и обновить их до 3.0.1, 2.28.5 либо 2.27.6, одновременно проверив установку GeoTools 35.1, 34.5 или 33.6 для соответствующей ветки. Публичный доступ лучше ограничить сетевыми правилами, а соединение GeoServer с PostgreSQL перевести с суперпользователя и ролей, обладающих pg_execute_server_program, на отдельную минимально привилегированную учётную запись. В журналах нужно искать массовые пробы, ошибки SQL, необычные запросы WFS 1.0, обращения к jsonArrayContains, признаки доступа к данным и запуск команд на узле базы. До выхода патчей рекомендовалось следить за обновлениями поставщика; теперь ожидание лишь оставляет уже известную точку входа открытой.
