115 000 сайтов на Drupal все еще уязвимы перед Drupalgeddon2

Олег Иванов 05 Июня 2018 - 12:31

Домашние пользователи

...

Спустя два месяца после того, как разработчики Drupal выпустили патч, устраняющий критическую уязвимость Drupalgeddon2, многие владельцы веб-сайтов до сих пор не установили эти обновления. Уязвимость Drupalgeddon2 отслеживается под идентификатором CVE-2018-7600, она получила статус «highly critical» (крайне опасная).

После публикации PoC-кода для эксплуатации это бреши эксперты отметили всплеск атак на сайт под управлением этой CMS.

Удивительно, что спустя два месяца все еще есть владельцы сайтов, которые предпочли остаться на уязвимых версиях движка Drupal.

Согласно исследованию, которое провел эксперт Трой Мурш, более 115 000 сайтов на Drupal все еще уязвимы для Drupalgeddon2. Такую статистику удалось получить благодаря анализу более 500 000 сайтов, которые использовали Drupal 7.x (сайты с версиями 6.x и 8.x не анализировались).

Результат — 115 070 сайтов по-прежнему уязвимы.

«Сколько сайтов на Drupal все еще уязвимы? Чтобы найти ответ на этот вопрос, я начал сканировать ресурсы, использующие Drupal 7. Это наиболее распространенная версия, согласно статистике Drupal. Я использовал PublicWWW, поисковую систему с открытым исходным кодом, благодаря чему смог сделать выборку из 500 000 веб-сайтов», — пишет в отчете эксперт.

Завершив санирование, эксперт выделил следующие моменты:

115 070 сайтов устарели и уязвимы;
134 447 сайтов в актуальном состоянии;
225 056 сайтов нельзя было идентифицировать.

Среди уязвимых сайтов были ресурсы крупных образовательных учреждений США, правительственных организаций по всему миру, крупной телевизионной сети, многонациональных СМИ и двух крупнейших производителей аппаратного обеспечения.

Исследователь поделился полученной информацией с US-CERT.

Более того, специалист обнаружил также новую вредоносную кампанию криптоджекинга, ориентированную на сайты на движке Drupal. Эксперт опубликовал электронную таблицу Google Docs, куда занес обнаруженные им данные.

Напомним, что в конец апреля разработчики Drupal выпустили дополнительный патч, устраняющий крайне опасную уязвимость в этой CMS, которая известна под именем Drupalgeddon2. Брешь получила идентификатор CVE-2018-7602, по словам разработчиков, она может позволить злоумышленнику получить контроль над сайтом, похитить информацию и видоизменить страницы.

Следующая главная новость »

Сбои, инциденты, простои: как мониторить ИТ в 2026?
Регистрируйтесь на эфир!

Екатерина Быстрова 22 Мая 2026 - 07:55

Уязвимости сайтов Уязвимости программ Домашние пользователи Корпорации

Миллионы серверов под угрозой: в NGINX обнаружили опасную уязвимость

В NGINX обнаружили новую 0-day уязвимость под названием nginx-poolslip. По предварительным данным, баг может позволить удалённо выполнять код на уязвимых серверах без аутентификации. Проблема затрагивает NGINX 1.31.0 — актуальную стабильную версию популярного веб-сервера.

Уязвимость обнаружил исследователь Vega из команды NebSec, публично о ней сообщили 21 мая 2026 года.

Согласно описанию, nginx-poolslip связана с внутренним механизмом управления памятью NGINX. Самое неприятное — заявлена возможность обхода ASLR, одной из базовых защит от эксплуатации ошибок памяти. Если обход действительно работает стабильно, это резко повышает шансы атакующего не просто уронить сервер, а выполнить свой код.

История выглядит особенно неприятно на фоне недавней уязвимости CVE-2026-42945 в ngx_http_rewrite_module, которую уже закрывали в версиях 1.31.0 и 1.30.1. Но, по данным NebSec, предыдущий патч не убрал саму поверхность атаки, а nginx-poolslip позволяет обойти прежние меры защиты.

На момент публикации у nginx-poolslip ещё нет идентификатора, а F5 и проект NGINX не выпустили официальный патч. NebSec заявляет, что следует процедуре ответственного раскрытия и опубликует технические детали только после появления патча.

Пока заплатки нет, администраторам советуют снижать риски вручную: следить за бюллетенями F5 и NebSec, ограничить доступ к административным интерфейсам, использовать WAF-правила, проверить включение ASLR, а также внимательно пересмотреть конфигурации с rewrite, if и set.

Масштаб проблемы серьёзный, NGINX используется как веб-сервер, обратный прокси, балансировщик и API-шлюз на огромном числе площадок.

Сбои, инциденты, простои: как мониторить ИТ в 2026?
Регистрируйтесь на эфир!