Drupal CVE-2026-9082 вынуждает PostgreSQL-сайты срочно устранять уязвимость

Каждый руководитель платформы, работающей на стеке Drupal + PostgreSQL, получил незапланированную статью расходов на май. Команда безопасности Drupal выпустила экстренные релизы для шести поддерживаемых версий, а также патчи «по возможности» для двух веток, вышедших из поддержки, чтобы закрыть уязвимость, позволяющую анонимным пользователям выполнять произвольную SQL-инъекцию. Главный бизнес-вопрос не в том, устанавливать ли патч на этой неделе. Он в том, как этот инцидент меняет соотношение «строить vs покупать» для команд, которые в 2026 году всё ещё рассматривают Drupal как стратегическую CMS.

Что произошло

21 мая 2026 года проект Drupal раскрыл уязвимость с рейтингом «высококритическая» в Drupal Core, отслеживаемую как CVE-2026-9082. Как сообщил The Hacker News, ошибка получила оценку CVSS 6.5 по CVE.org, что выглядит странно низко на фоне собственного определения проекта «высококритическая». Это расхождение имеет значение, и я вернусь к нему ниже.

Первопричина находится в API абстракции базы данных, который Drupal Core использует для проверки запросов и защиты от SQL-инъекций. Специально сформированный запрос может обойти эту защиту и привести к произвольной SQL-инъекции, но только на сайтах с PostgreSQL. Развёртывания на MySQL и MariaDB, согласно собственному предупреждению Drupal, не затронуты. Цепочка воздействия охватывает диапазон от раскрытия информации до повышения привилегий и, в ряде случаев, удалённого выполнения кода (RCE). Принципиально важно, что атака не требует аутентификации. Анонимные пользователи из публичного интернета могут её предпринять.

Исправленные релизы доступны для поддерживаемых веток: Drupal 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10 и 10.4.10. Поддерживаемые ветки (11.3, 11.2, 10.6 и 10.5) также включают обновления безопасности для Symfony и Twig, а значит патч — это не замена одного файла, а обновление зависимостей. Drupal 7 не затронут. Drupal 8 и Drupal 9 вышли из поддержки, однако с учётом серьёзности уязвимости проект выпустил ручные патчи для 9.5 и 8.9 в режиме «лучших усилий». Drupal 11.1.x, 11.0.x, 10.4.x и ниже находятся в зоне без покрытия. Официальную информацию об уязвимости можно найти в записи CVE.

Техническая анатомия

Механизм уязвимости заслуживает внимания, поскольку объясняет, почему оценка CVSS расходится с формулировкой серьёзности от проекта. Уровень абстракции базы данных в Drupal существует именно для того, чтобы разработчики приложений не писали SQL-запросы вручную под каждый бэкенд. Этот уровень нормализует привязку параметров, экранирование и обработку идентификаторов для MySQL, PostgreSQL и SQLite. Когда сама абстракция ломается на одном из бэкендов, все модули, работающие поверх неё, наследуют уязвимость — даже те, авторы которых сделали всё правильно. Именно поэтому единственный CVE в Core может затронуть тысячи контриб-модулей, не имея индивидуальных уязвимостей в каждом из них.

Ограниченный радиус поражения только PostgreSQL указывает на специфическое поведение при экранировании или приведении типов в драйвере этой СУБД. PostgreSQL обрабатывает ряд граничных случаев с идентификаторами и строковыми литералами иначе, чем MySQL, — особенно в отношении чувствительности к регистру, долларового экранирования и синтаксиса массивов. Санитайзер, рассчитанный на семантику MySQL, даёт течь на Postgres. Drupal не раскрывает детали эксплойта — и правильно делает, — но форма уязвимости соответствует несовместимости на уровне драйвера, а не логической ошибке в конкретном модуле.

Путь эскалации от SQL-инъекции до RCE в Drupal хорошо известен. Как только атакующий может записывать произвольные строки, целями становятся таблицы кэша, таблица сессий и таблицы конфигурации, хранящие сериализованные PHP-объекты. Внедрите сформированную сериализованную полезную нагрузку, спровоцируйте десериализацию при следующем запросе — и получите выполнение кода от имени пользователя веб-сервера. Это чётко соответствует техникам MITRE ATT&CK в области эксплуатации публично доступных приложений и серверной десериализации. Оценка CVSS 6.5, по всей видимости, отражает условный характер пути к RCE (не все сайты имеют доступные для записи таблицы конфигурации на уровне кэша), но для финансового директора, визирующего резерв на инциденты, важен наихудший сценарий, а не медианный.

Обновления Symfony и Twig, включённые в релизы поддерживаемых веток, добавляют ещё одну сложность. Команды, которые обновят только файлы Drupal Core, не обновив директорию vendor, будут считать себя защищёнными, хотя это не так.

Кто пострадает

Круг уязвимых уже, чем при типичном CVE в Drupal Core, но концентрация проблемы жёсткая. Drupal на PostgreSQL — не стандартный стек. Он чаще всего встречается в трёх секторах: государственные сайты в Европе, где Postgres является обязательным требованием; порталы высших учебных заведений, унаследовавших Postgres от более широкого институционального стандарта; а также регулируемые отрасли — страхование, здравоохранение, смежные fintech-направления, — где команда платформы выбрала Postgres ради JSONB или по лицензионным соображениям. Именно эти операторы отличаются наиболее медленными циклами управления изменениями и наибольшими накладными расходами на соответствие требованиям при каждом развёртывании.

Вопрос финансового директора на этой неделе — тот, который юридический директор задаст первым: есть ли у нас Drupal на Postgres где-либо в инфраструктуре, и если да, каков наш срок уведомления о защите данных, если мы не можем подтвердить, что нас ещё не взломали? Возможность эксплуатации анонимными пользователями означает, что в журналах аутентификации нечего искать. Обнаружение зависит от телеметрии WAF и журналов запросов к базе данных, которые большинство среднерыночных операторов Drupal не хранят с достаточной детализацией для ретроспективной криминалистики.

Наиболее уязвимые — это те, кто до сих пор работает на Drupal 8, 9 или на ветках 10.x, вышедших из поддержки. Патчи «по возможности» для 8.9 и 9.5 — это жест вежливости, а не обязательство. Drupal прямо указал, что в этих версиях остаются другие ранее раскрытые уязвимости. Если вы работаете на 8.9 в 2026 году, этот CVE — симптом, а не болезнь. Настоящая проблема в том, что ваша платформенная команда откладывала обновление до мажорной версии до того момента, когда отсрочка обходится дороже риска взлома.

На рынке найма ожидайте краткосрочного всплеска спроса на специалистов по обновлению Drupal — аналогично тому мини-буму контракторов, который случился после окончания поддержки Magento 1. Предложение скудное: опытные Drupal-инженеры последние три года тихо переходят на headless и JAMstack.

Сценарий действий для команд безопасности

Начните с инвентаризации, а не с установки патчей. Вы не можете устранить уязвимость в том, о чём не знаете. Выгрузите все хосты Drupal из системы управления активами, определите бэкенд базы данных (Postgres или MySQL) и пометьте Postgres-сайты как приоритет первого уровня. MySQL-сайты тоже нужно обновлять, но срочность ниже, поскольку конкретный CVE их не затрагивает.

Для сайтов на Postgres в поддерживаемой ветке обновитесь до 11.3.10, 11.2.12, 10.6.9 или 10.5.10 в зависимости от вашей версии. Обновите директорию vendor: обновления Symfony и Twig включены в тот же релиз не случайно. Проведите дымовое тестирование в staging-среде на самых посещаемых типах контента и всех кастомных модулях, обращающихся к db_query или entity query API.

Для сайтов на Postgres с версиями 11.1.x, 11.0.x, 10.4.x или ниже у вас два пути: либо перейти на поддерживаемую ветку в этом квартале, либо принять, что вы работаете на неподдерживаемой инфраструктуре, и соответствующим образом оценить риск. Для 9.5 и 8.9 — примените ручные патчи как временную меру, но воспринимайте их как жизнеобеспечение, а не как решение. Всё, что работает на Drupal 7, не затронуто этим CVE, однако сам Drupal 7 уже вышел из поддержки и несёт собственный портфель неисправленных проблем.

На стороне обнаружения: настройте WAF на аномальные строки запросов, обращающихся к эндпоинтам Drupal; логируйте все ошибки класса 500 от PHP; снимите базовый срез паттернов запросов к базе данных прямо сейчас, чтобы было с чем сравнивать при обнаружении признаков компрометации. Ежедневно проверяйте каталог CISA KEV в течение следующих двух недель. Если CVE там появится, федеральные подрядчики получают жёсткий дедлайн по устранению вне зависимости от внутренних окон изменений.

Руководитель платформы должен на этой неделе спросить у вице-президента по инжинирингу: есть ли у Drupal-инфраструктуры дорожная карта вывода из эксплуатации с конкретной датой завершения, или она дрейфует, потому что никто не принял решения? Этот разговор давно назрел вне зависимости от CVE-2026-9082, а патч-цикл — удобный повод внести его в повестку.

Ключевые выводы

• CVE-2026-9082 — это SQL-инъекция в API абстракции базы данных Drupal Core, доступная анонимным пользователям, с путём к RCE только на сайтах с PostgreSQL.
• Исправленные версии: Drupal 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10 и 10.4.10; релизы поддерживаемых веток также включают обновления Symfony и Twig, которые необходимо применить вместе.
• Drupal 8.9 и 9.5 получают ручные патчи «по возможности», несмотря на выход из поддержки; более старые версии 10.x и 11.x не получают ничего.
• CVSS 6.5 занижает операционную серьёзность, поскольку усредняет условные пути эскалации; относитесь к анонимно достижимой SQLi как к инциденту первого приоритета.
• Командам, рассматривающим Drupal как стратегическую платформу в 2026 году, следует задаться вопросом: по-прежнему ли стоимость владения самостоятельно размещённой PHP CMS меньше, чем стоимость миграции на управляемую или headless-альтернативу.