Drupal заранее попросила администраторов освободить окно на 20 мая под критический патч Drupal: уязвимость в ядре получила 20 баллов из 25 по внутренней шкале проекта. Для российских команд, которые держат на Drupal корпоративные сайты, медиа, intranet и госвеб, это прямой сигнал не откладывать обновление «на вечер» и проверить, кто вообще дежурит по продакшену.
О проблеме сообщает The Register со ссылкой на предупреждение Drupal Security Team. Команда проекта не раскрывает технические детали до выхода исправления, но уже сейчас описывает риск достаточно жестко: уязвимость находится в Drupal core, эксплуатируется без привилегий, может открыть доступ ко всем непубличным данным сайта, а также позволить изменять или удалять контент. Иными словами, это не история про «подправить версию при случае», а сценарий, в котором после публикации патча у атакующих может появиться рабочая цепочка буквально в течение часов или дней.
Исправления должны были выйти в среду, 20 мая, в промежутке с 17:00 до 21:00 UTC. Drupal отдельно предупредила, что резервировать время нужно не только на установку апдейта, но и на быструю проверку, относится ли конкретная инсталляция к уязвимому классу. И здесь есть неприятная деталь: проблема затрагивает не все конфигурации, а только сайты с «необычными комбинациями модулей». С одной стороны, это убирает максимальный балл по шкале severity. С другой, как раз такие формулировки обычно усложняют жизнь большим командам: нужно не просто обновиться, а сначала понять, не прячется ли риск в старой сборке, которую несколько лет допиливали «точечно и без лишнего шума».
Drupal уточняет, что речь идет именно о ядре как базовой версии системы для разработчиков, а не только о Drupal CMS в виде преднастроенной сборки для менее технических пользователей. Позже проект дополнительно предупредил, что из-за наличия core внутри Drupal CMS такие окружения тоже могут оказаться уязвимыми. Проще говоря, разделение «мы на CMS, а не на голом core» в этот раз не спасает: проверяться придется всем, у кого вообще крутится Drupal.
Для поддерживаемых веток исправления обещаны штатно: 11.3.x, 11.2.x, 10.6.x и 10.5.x. Но показателен другой момент: из-за потенциальной тяжести бага обновления подготовили даже для неподдерживаемых веток 11.1.x и 10.4.x, а также для совсем старых 9.5 и 8.9. Это редкий жест, который хорошо показывает уровень тревоги внутри проекта. При этом владельцам Drupal 8.9 и 9.5 расслабляться не предлагают: патчи для них придется ставить вручную, а сама команда предупреждает о возможных побочных эффектах и регрессиях. Рекомендация прозрачная — переходить на поддерживаемую ветку, потому что в Drupal 8 и 9 уже накоплены другие ранее раскрытые уязвимости, которые этот экстренный фикс не закроет.
Почему это неприятный сигнал для команд
В истории с критическим патчем Drupal важен не только балл, но и тайминг. Проект фактически заранее сообщил рынку: «в среду будет плохо, подготовьтесь». Для защитников это шанс собрать людей, сделать бэкапы и прогнать обновление без паники. Для атакующих это тоже сигнал: после публикации diff между версиями станет быстрым способом понять, что именно закрыли. На практике такие окна часто превращаются в гонку между администраторами и теми, кто пишет эксплойт по свежему патчу.
Отдельно показательно упоминание Drupal Steward, платного WAF-сервиса проекта. Команда заявляет, что его клиенты защищены от известных векторов атаки, но все равно рекомендует обновлять ядро. Это важная оговорка для бизнеса, который любит верить, что внешний щит решает все. Не решает. WAF может помочь пережить первые часы, но если уязвимость допускает дополнительные способы эксплуатации, без обновления ядра сайт остается в подвешенном состоянии. Для CTO и ИБ-команд вывод банален, но почему-то до сих пор не у всех оформлен в процесс: компенсирующие меры хороши как страховка, а не как замена патч-менеджменту.
Есть и еще один слой проблемы: многие компании сидят на старых ветках Drupal не потому, что им нравится риск, а потому что миграция давно стала отдельным проектом с бюджетом, подрядчиками и внутренней политикой. Именно по таким инсталляциям подобные предупреждения бьют сильнее всего. Если у вас Drupal 8.9 или 9.5, новость означает не только срочное ручное обновление, но и неприятный разговор о техническом долге, который уже нельзя прятать за фразой «сайт же работает». Когда проект выпускает экстренные патчи даже для неподдерживаемых веток, он фактически сообщает: дальше тянуть просто опасно.
Что делать прямо сейчас
Для разработчиков и администраторов список действий довольно приземленный. Проверить ветку ядра, сверить набор модулей, подготовить стенд или хотя бы резервную копию, освободить окно на установку и заранее оценить, кто принимает решение, если после апдейта что-то ломается. Сам патч, по словам Drupal, может ставиться за минуты или даже секунды в зависимости от сайта и, вероятно, без отключения ресурса. Но это как раз тот случай, когда «ставится быстро» не означает «можно заняться потом». Чем позже команда обновится после публикации исправления, тем выше шанс оказаться в хвосте тех, кого догнали уже готовые публичные техники эксплуатации.
В более широком смысле критический патч Drupal снова напоминает старую, но неудобную вещь: open source не делает скидку на то, что у вас нет времени на апгрейды. Если CMS годами живет как тихий инфраструктурный фон, это не значит, что она перестала быть частью поверхности атаки. И когда проект начинает будить администраторов заранее, вплоть до старых 8.9-веток, это уже не просто очередной advisory, а проверка зрелости процессов у всех, кто привык считать контентную платформу второстепенным сервисом.