Уязвимость в PHP оказалась критичнее, чем казалось на первый взгляд. По словам гендиректора Cloudflare Мэтью Принса, сеть компании зафиксировала миллионы попыток эксплуатации — причём атаки начались задолго до того, как об уязвимости объявили публично. Это указывает на то, что информация о проблеме распространялась через приватные каналы или была выявлена независимо несколькими группами почти одновременно.
Масштаб атак необычен даже для критических уязвимостей. Если попытки идут с такой интенсивностью до официального раскрытия, значит, уязвимость либо очень легко найти и использовать, либо информация о ней активно торговалась в закрытом сегменте киберпреступного сообщества. Оба сценария означают, что любой хост, на котором крутится уязвимая версия PHP, стоял под прицелом практически сразу.
Для администраторов серверов это напоминание о классической проблеме: даже когда подготовка патча идёт в публичном репозитории (как у PHP), враги часто замечают грядущие исправления раньше, чем их развернёт большинство пользователей. И когда часы до официального разглашения считаются днями, уже слишком поздно. Облачные провайдеры вроде Cloudflare получают картину в реальном времени — видят весь трафик, но не могут защитить всех остальных, которые работают на собственной инфраструктуре и не следят за новостями круглосуточно.
Контекст усугубляет ситуацию: PHP — язык для веб-приложений, и уязвимость в его ядре потенциально касается десятков миллионов хостов. Если это исполнение кода, утечка данных или обход аутентификации, разница в пару часов между узнаванием о проблеме и развёртыванием патча может обойтись в компрометацию баз данных, учётных записей администраторов и полный контроль над серверами. Опыт показывает: когда облачники начинают говорить о «миллионах попыток», это не маркетинг — это признак того, что уязвимость действительно критична и массово эксплуатируется.
Для российского бизнеса, который держит веб-приложения на PHP-хостингах (а это всё ещё огромная часть российского интернета — от небольших сайтов до e-commerce), ситуация требует немедленного действия. Первое: обновить PHP до патченной версии, если это сделано — хорошо, если нет — это вопрос часов, не дней. Второе: мониторить логи доступа на предмет странных запросов, которые могли пройти до обновления. Третье: если есть возможность использовать WAF (Web Application Firewall) через Cloudflare, Sucuri или аналогичные сервисы, это снижает риск даже для не обновлённых приложений, хотя заменой патчу не является. Для крупных приложений на собственной инфраструктуре имеет смысл подписаться на каналы уведомлений PHP-сообщества (php.net) и настроить автоматическое развёртывание обновлений — технологии вроде Docker и систем управления конфигурацией позволяют это делать в минуты, а не часы.
Случай с PHP-уязвимостью — ещё один пример того, почему теория «защиты глубиной» работает: одного фаервола или WAF недостаточно, нужны и актуальные обновления, и мониторинг, и изоляция критических систем. Для компаний, критичные системы которых работают на PHP или других языках с активным жизненным циклом, это повод пересмотреть цикл обновлений и не полагаться только на облачные фильтры.