О чем предупреждает Drupal#
Drupal сообщает, что уже видит попытки эксплуатации CVE-2026-9082 — уязвимости с оценкой highly critical, исправленной на этой неделе.
Проблема находится в API, который используется для очистки запросов к базе данных и защиты от SQL injection. По данным Drupal, ошибка позволяет атакующему отправлять специально сформированные запросы, которые могут привести к произвольной SQL injection на сайтах с базой PostgreSQL.
Важно не расширять масштаб проблемы сверх того, что сказано в бюллетене. Уязвимость не описана как универсальная для всех установок Drupal и всех database backend. Заявленное влияние привязано к сайтам Drupal, работающим с PostgreSQL. По оценке Drupal, затронуто менее 5% сайтов, хотя сама CMS используется на сотнях тысяч сайтов.
Уязвимость могут использовать неаутентифицированные атакующие. В бюллетене Drupal сказано, что эксплуатация может привести к раскрытию информации, а в отдельных случаях — к повышению привилегий и RCE. Эти последствия не одинаковы для каждой среды. Худший сценарий зависит от конфигурации конкретного сайта и от того, куда атакующий сможет продвинуться после SQL injection.
Drupal заранее предупреждал, что эксплойт для CVE-2026-9082 может появиться через часы или дни после раскрытия. Этот прогноз, похоже, оказался верным по направлению: позже бюллетень обновили, указав на активные попытки эксплуатации в реальных атаках.
Почему оценку риска повысили#
Drupal использует систему NIST CMSS для оценки уязвимостей, где максимум — 25 баллов. Бюллетень по CVE-2026-9082 обновили 22 марта: оценка риска выросла с 20 до 23.
Причина простая: попытки эксплуатации теперь фиксируются в реальных условиях.
Это не означает автоматически, что уже произошли массовые успешные взломы. Но уязвимость вышла из чисто теоретической фазы. Когда сканеры и оппортунистические атакующие начинают проверять баг в масштабах интернета, защитники теряют преимущество неизвестности и времени.
Для уязвимостей в CMS это особенно важно. Публичные экземпляры CMS легко перечислять. Атакующие часто могут быстро проверять большое число сайтов. Если существует надежный путь эксплуатации, интервал между раскрытием, сканированием и компрометацией может быть коротким.
SecurityWeek также отмечает более широкий контекст Drupal. Уязвимости уровня highly critical в Drupal не исправлялись годами, а недавние баги Drupal обычно не фигурировали как активно эксплуатируемые. Старые уязвимости Drupal до 2019 года стали широко известны, потому что их использовали для взлома множества сайтов. Эта история не доказывает, что CVE-2026-9082 пойдет тем же путем, но объясняет, почему ранние признаки эксплуатации уязвимости уровня highly critical в Drupal привлекают внимание.
Что увидела Imperva#
Imperva сообщила о более чем 15 000 попыток эксплуатации почти против 6 000 сайтов в 65 странах.
Почти половина атак, которые наблюдала Imperva, была направлена на сайты игровой индустрии и финансовых сервисов. При этом отчет не доказывает, что все атакованные сайты были уязвимы или скомпрометированы. Трактовка Imperva осторожнее: активность больше похожа на разведку и проверку.
То есть атакующие и сканеры, вероятно, сначала пытаются ответить на базовые вопросы:
- Работает ли сайт на Drupal?
- Используется ли уязвимая версия?
- Стоит ли за сайтом PostgreSQL?
- Дает ли специально сформированный запрос полезный ответ?
Эта стадия все равно важна. Разведка помогает атакующим собирать списки целей. Если сайт отвечает так, что подтверждает экспозицию, его могут передать в следующий pipeline эксплуатации. Для SQL injection следующая фаза может перейти от простого прощупывания к извлечению данных, поиску путей захвата учетных записей, повышению привилегий или попыткам выйти на выполнение кода там, где среда это позволяет.
Поэтому предупреждение Imperva сдержанное, но серьезное: текущая активность может в основном быть сканированием, однако характер уязвимости означает, что успешная эксплуатация способна быстро усилиться.
Что владельцам сайтов проверить в первую очередь#
Главный вопрос: использует ли ваша установка Drupal PostgreSQL.
Если нет, конкретная экспозиция, описанная в бюллетене, может не применяться тем же образом. Но это нужно проверить по официальным рекомендациям Drupal и по фактической конфигурации, а не по памяти или старой документации.
Для команд, которые эксплуатируют Drupal, практический список действий прямой:
- Подтвердить версию Drupal и проверить, установлен ли нужный патч.
- Подтвердить database backend для каждого публичного сайта на Drupal.
- В первую очередь разобрать Drupal-инстансы с PostgreSQL.
- Проверить логи web application firewall, CDN и приложения на подозрительные запросы вокруг даты раскрытия.
- Искать признаки прощупывания SQL injection, необычные ошибки базы данных или неожиданные изменения привилегий.
- Пересмотреть учетные записи администраторов и недавно измененные роли или разрешения.
- Считать публичные непатченные сайты Drupal с PostgreSQL срочными.
В managed-средах запросите у хостинг-провайдера или владельца приложения явное подтверждение. «Drupal управляется провайдером» не то же самое, что «эта уязвимость исправлена». Операционный вопрос в том, существует ли уязвимый путь выполнения кода и развернут ли патч в работающей системе.
Чего не стоит утверждать сверх фактов#
Несколько вещей нужно держать отдельно.
Во-первых, активные попытки эксплуатации не равны подтвержденной массовой компрометации. Источники сообщают о попытках эксплуатации и масштабном таргетинге. Они не говорят, что тысячи сайтов были успешно взломаны.
Во-вторых, Drupal оценивает долю затронутых сайтов менее чем в 5%, потому что ошибка связана с конфигурациями на PostgreSQL. Это снижает общий пул риска, но не снижает срочность для сайтов, попавших в эту долю.
В-третьих, возможное влияние включает RCE в отдельных случаях, но это не означает, что каждый уязвимый сайт автоматически открыт для RCE. Последствия SQL injection зависят от прав базы данных, поведения приложения, конфигурации и доступности вторичных путей атаки.
В-четвертых, трафик сканеров все равно опасен. Ранняя разведка часто выглядит шумной и примитивной. Но именно она может выделить подмножество систем, которые позже получат более прицельную эксплуатацию.
Практический вывод#
CVE-2026-9082 достаточно узкая, чтобы не паниковать, и достаточно серьезная, чтобы быстро все проверить.
Если вы используете Drupal с PostgreSQL, не откладывайте патчинг и проверку логов. Если Drupal работает без PostgreSQL, подтвердите это и продолжайте следить за бюллетенем, но держите риск в правильной пропорции. Если вы управляете множеством сайтов Drupal, первым контролем должна стать инвентаризация: database backend, состояние патчей, доступность из интернета и владелец.
Ключевой сигнал — не только оценка уязвимости. Важны сроки. Drupal ожидал быстрого появления эксплойтов. Оценка риска в бюллетене выросла после обнаружения попыток эксплуатации. Затем Imperva сообщила о широком сканировании тысяч сайтов.
Так обычно выглядит переход бага в CMS в рабочие процессы атакующих. Полезный ответ — не драматизация, а быстрая проверка, установка патчей и разбор по фактам тех систем, которые с наибольшей вероятностью находятся под риском.