20 мая 2026 года команда Drupal выпустила security advisory SA-CORE-2026-004 по SQL-инъекции в Drupal Core. Риск касается сайтов, которые используют PostgreSQL, а исправления уже доступны для веток Drupal 10 и 11. Владельцам сайтов важно быстро проверить версию, базу данных и план обновления, потому что уязвимость может использоваться анонимным пользователем.
Drupal закрыл SQL-инъекцию в ядре CMS
Команда Drupal опубликовала официальное предупреждение SA-CORE-2026-004 20 мая 2026 года. Уязвимость получила идентификатор CVE-2026-9082 и относится к классу SQL injection — это ситуация, когда злоумышленник может подмешать в запрос к базе данных собственные SQL-команды.
В обычной работе CMS должна безопасно формировать запросы к базе: получать записи, фильтровать материалы, проверять права, выводить нужный контент. Для этого Drupal использует слой абстракции базы данных — внутренний механизм, который помогает разработчикам не писать прямые SQL-запросы вручную. Ошибка оказалась именно в этой части ядра.
По описанию Drupal, специально подготовленные запросы могут привести к произвольной SQL-инъекции на сайтах, которые работают с PostgreSQL. Потенциальные последствия серьёзные: раскрытие информации, повышение привилегий, удалённое выполнение кода или другие атаки в зависимости от конфигурации сайта.
Риск ограничен PostgreSQL, но обновление полезно не только таким сайтам
Главное уточнение: сама SQL-инъекция затрагивает только сайты Drupal, использующие PostgreSQL. Если проект работает на MySQL, MariaDB или SQLite, именно эта уязвимость на него не распространяется.
Но это не значит, что обновление можно полностью игнорировать. В релизы Drupal 10 и 11, выпущенные вместе с advisory, также вошли обновления сторонних зависимостей Symfony и Twig. Drupal прямо рекомендует обновиться даже тем сайтам, которые не затронуты PostgreSQL-частью проблемы, потому что отдельные исправления в зависимостях могут быть актуальны для разных конфигураций и модулей.
Для владельца сайта практический вывод простой: сначала нужно определить, какая база данных используется в проекте, но финальное решение лучше принимать не только по этому признаку. Если сайт находится на поддерживаемой ветке Drupal, безопаснее запланировать обновление до исправленной версии.
Анонимная эксплуатация делает проблему особенно неприятной
В advisory указано, что уязвимость может быть использована анонимными пользователями. Это важная деталь: атакующему не обязательно иметь учётную запись в админке или доступ к закрытым разделам сайта.
Drupal оценил риск как Highly critical — 20 из 25 по собственной шкале проекта. В такой оценке учитываются не только формальные баллы CVSS, но и практическая опасность для реального сайта: доступность атаки, влияние на конфиденциальность данных, возможность изменения данных и потенциальные цепочки дальнейшей эксплуатации.
Tenable в своём разборе отметил, что на момент публикации 21 мая не было подтверждённых сообщений об эксплуатации в реальных атаках, но также указал на появление detection PoC и публичный патч-дифф в день раскрытия. Это сокращает окно между публикацией исправления и возможными попытками массовой эксплуатации.
Исправленные версии уже доступны для Drupal 10 и 11
Drupal рекомендует установить последнюю исправленную версию своей ветки:
| Ветка Drupal | Исправленная версия |
| Drupal 11.3.x | 11.3.10 |
| Drupal 11.2.x | 11.2.12 |
| Drupal 11.1.x или 11.0.x | 11.1.10 |
| Drupal 10.6.x | 10.6.9 |
| Drupal 10.5.x | 10.5.10 |
| Drupal 10.4.x и более ранние версии Drupal 10 | 10.4.10 |
Отдельно Drupal сообщает, что Drupal 8 и Drupal 9 уже достигли конца жизненного цикла. Из-за серьёзности проблемы для них опубликованы best-effort-патчи, но это не превращает устаревшие ветки обратно в полноценно поддерживаемые. У таких сайтов могут оставаться другие известные уязвимости, которые уже не закрываются штатными security-релизами.
Drupal 7, по данным публикаций по advisory, этой конкретной уязвимостью не затронут. Но для старых проектов это всё равно повод проверить общую стратегию поддержки: чем дольше сайт живёт на устаревшей платформе, тем сложнее становится безопасно поддерживать его в рабочем состоянии.
Владельцам сайтов нужно проверить базу данных, версию ядра и процесс обновления
Для администратора или владельца сайта порядок действий выглядит так:
- Проверить, используется ли PostgreSQL.
- Определить текущую версию Drupal Core.
- Сравнить её со списком исправленных версий.
- Сделать резервную копию файлов и базы данных.
- Проверить обновление на тестовой копии, если проект критичен для бизнеса.
- Обновить ядро Drupal и зависимости.
- После обновления проверить работу форм, фильтров, поиска, пользовательских ролей и административных разделов.
Если сайт обслуживает подрядчик, стоит не просто переслать ему новость, а запросить короткое подтверждение: какая версия Drupal установлена, какая база используется, требуется ли срочное обновление и когда оно будет выполнено.
Разработчикам стоит отдельно проверить модули и пользовательские роли
На сложных Drupal-проектах риск не всегда ограничивается самим ядром. Важны установленные contributed-модули, кастомные доработки, права пользователей и механизмы, которые работают с представлениями, шаблонами или динамическими запросами.
Drupal отдельно обращает внимание на обновления Symfony и Twig, а также рекомендует проверить роли, которые могут изменять Twig-шаблоны, например через Views или дополнительные модули. Это не означает, что каждый сайт автоматически уязвим по нескольким направлениям, но показывает правильный подход: security-релиз нужно рассматривать не как формальную замену версии, а как повод проверить всю цепочку исполнения кода и прав.
Для небольших сайтов задача обычно сводится к обновлению ядра и зависимостей. Для корпоративных проектов лучше добавить проверку логов, внешнего периметра, резервных копий и списка публично доступных Drupal-инсталляций.
Быстрое обновление снижает риск до начала массовых атак
SA-CORE-2026-004 — это срочное исправление в ядре популярной CMS. Новость особенно важна для сайтов на PostgreSQL: именно они находятся в основной зоне риска по CVE-2026-9082.
Если проект работает на Drupal 10 или 11, правильный следующий шаг — проверить ветку и обновиться до исправленной версии. Если сайт находится на Drupal 8 или 9, одного временного патча недостаточно для спокойной поддержки: нужно планировать миграцию на актуальную ветку. В подобных случаях безопасность зависит не только от одного исправления, а от способности проекта регулярно получать security-обновления.
