Исправление для PHP2Shell уже выпущено, но для большинства сайтов, которым оно необходимо, кнопки «установить» просто нет. Уязвимости находятся в самом PHP — движке, на котором работает каждая страница WordPress, Joomla и Drupal, ниже уровня CMS, её плагинов и экрана входа. Обновление WordPress здесь ничего не меняет. Исправленную версию интерпретатора должен предоставить тот, кто управляет сервером: хостинг-провайдер, пакет дистрибутива Linux или образ контейнера. Пока этого не произошло, сайт остаётся ждать — что бы ни предпринимал его владелец.

Именно об этой стороне истории обычно умалчивают заголовки в духе «срочно установите исправление». Команда PHP свою работу выполнила. Но попадёт ли результат на конкретный сервер, зависит от цепочки поставки, скорость которой определяется самым медленным звеном. Уже в первый день стало ясно, насколько сильно эти звенья отстают друг от друга. Владелец, который не знает, откуда его сервер получает PHP, не может понять, насколько сайт всё ещё уязвим.

Почему обновление WordPress не решает проблему

Поскольку ошибки находятся в интерпретаторе, предупреждение PHP касается каждой установки, обрабатывающей веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Как отмечает The Hacker News, атаке может подвергнуться даже простая страница «Hello World», работающая на уязвимой версии. Наиболее опасный сценарий связан с mod_php: одного запроса от пользователя без учётной записи достаточно, чтобы запустить атаку ещё до выполнения кода приложения. Поэтому её не обнаружит ни плагин безопасности, ни экран входа.

Wordfence, поставщик средств безопасности для WordPress, сообщил владельцам сайтов, что исправление не может прийти через автоматические обновления и им нужно выяснить, кто отвечает за используемую версию PHP. Об этом рассказало издание The Verge. Laravel Forge сообщил то же самое своим клиентам применительно к серверам платформы: автоматические обновления безопасности не исправляют PHP, а механизм unattended upgrades в Ubuntu получает обновления только из собственного репозитория Ubuntu, но не из сторонних пакетов, откуда Forge устанавливает PHP.

Источники пакетов обновлялись не одновременно. В день выпуска сервис управления сайтами mySites.guru сообщил, что в EasyApache 4 от cPanel исправленные сборки появились через несколько минут после публикации предупреждений, тогда как в PPA Ондржея Сури (Ondřej Surý), на который опирается Laravel Forge, и в репозитории Remi их пока не было. InMotion Hosting заявил, что его общие серверы и серверы для WordPress ожидали сборки от CloudLinux. Среди работающих сайтов, которые отслеживает mySites.guru, к 13:52 UTC исправленная версия PHP была установлена лишь на 0,08%.

Номер версии может ввести в заблуждение

Проверить наличие исправления не так просто, как посмотреть на номер версии. Ubuntu, Debian и Red Hat переносят исправления безопасности в старые версии, не меняя номер версии исходного релиза, поэтому на исправленном сервере Ubuntu 24.04 по-прежнему может отображаться пакет 8.3.6. The Hacker News со ссылкой на Debian советует искать CVE в журнале изменений пакета, а не доверять строке с номером версии. mySites.guru указывает и на другую ловушку: исполняемый файл PHP, который выдаёт результат команды php -v в командной строке, часто отличается от того, что обслуживает страницы. Поэтому проверять нужно версию, которую показывает сам сайт.

Затем необходимо загрузить исправление. В предупреждении PHP и в сообщении Forge особо подчёркивается, что нужно перезапустить Apache, PHP-FPM и все долго работающие процессы. Обработчики очередей и другие фоновые процессы продолжат использовать старый интерпретатор, пока их не перезапустят, даже если исправленные файлы уже лежат на диске.

Кто не получит официального исправления

Исправленные версии — PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они устраняют CVE-2026-109618 и CVE-2026-109619, обе уязвимости получили оценку 9,2 по CVSS v4.0. Для PHP 8.1 и более ранних версий проект PHP не предоставляет ничего, кроме минимальных исправлений исходного кода для версий 7.4, 8.0 и 8.1, предназначенных для тех, кто самостоятельно собирает PHP. Некоторые поставщики восполняют этот пробел: InMotion сообщает, что cPanel перенёс исправления в свои пакеты для версий с 7.4 по 8.1, а CloudLinux исправляет все распространяемые им версии. Для CentOS 7 исправления не будет.

Таких устаревших установок немало. За день до выпуска 22,7% работающих сайтов на Joomla и WordPress, которые отслеживает mySites.guru, использовали PHP 8.1 или более раннюю версию, а 16,6% всё ещё работали на PHP 7 или старше. Компания связывает часть проблемы с самим WordPress: он рекомендует PHP 8.3, но по-прежнему указывает давно снятую с поддержки версию 7.4 как совместимую. PHP 8.2 получит это исправление, однако её поддержка безопасности закончится 31 декабря 2026 года.

Что блокирует временная настройка

Решение, которое распространялось до выхода исправления, — установить session.upload_progress.enabled=0 — действительно помогает, но лишь частично. По данным PHP, оно блокирует подтверждённые сценарии атаки на CVE-2026-109619, связанные с сессиями, но не другие варианты. Настройку нужно задать в php.ini, конфигурации сервера или пула, а затем перезапустить все процессы. В PHP 8.5 ещё один подтверждённый сценарий закрывает параметр fatal_error_backtraces=0. Ни одна из этих мер не затрагивает CVE-2026-109618. Для неё PHP предлагает задать не допускающий переопределения параметр memory_limit=-1, установить низкое значение post_max_size и ограничить размер запросов на веб-сервере или прокси. В самом PHP подчёркивают: полностью устранить риск с помощью временных мер нельзя. InMotion отмечает, что WordPress, Joomla, Drupal, Magento и PrestaShop не используют отслеживание хода загрузки файлов, поэтому его отключение для них ничего не сломает.

Cloudflare включила правила межсетевого экрана для всех тарифов; технический директор компании Дейн Кнехт (Dane Knecht) назвал это временной мерой. Как отмечает mySites.guru, правила помогут только в том случае, если сервер за Cloudflare блокирует трафик, который пытается обойти сервис и обратиться напрямую к IP-адресу сервера.

Первые атаки

Компания watchTowr сообщает, что в день выпуска её ловушки зафиксировали попытки эксплуатации обеих уязвимостей, а Cloudflare заметила, что злоумышленники меняли полезную нагрузку, чтобы обходить правила сервиса. Ни один источник не подтвердил успешный взлом конкретного сервера. Некоторые операторы решили не рисковать: The Hacker News сообщает, что BambooHR отключила свой сервис, а государственные онлайн-службы Нидерландов, включая DigiD, временно перестали работать в качестве меры предосторожности. CERT ЕС и Национальный центр кибербезопасности Великобритании рекомендовали организациям, которые не могут установить исправление, изолировать уязвимые приложения или отключить их.

Уязвимости обнаружили Wiz Research, Calif и команда Codex Security из OpenAI. По данным PHP Foundation, первые признаки проблемы с памятью появились во время аудита в 2024 году, однако работа над исправлением на несколько месяцев застопорилась. В фонде назвали эту задержку «системным сбоем». Исследователи утверждают, что модели ИИ помогли превратить ошибки десятилетней давности в работающие эксплойты примерно за неделю.

Чтобы выпустить это исправление, PHP понадобились аудит, месяцы безрезультатных споров и утечка информации. Для сайта на общем хостинге последний шаг — написать в службу поддержки.

Теги: Cloudflare, PHP, PHP2Shell, WordPress, уязвимости