Критическая уязвимость PHP php2shell: что делать сейчас

Согласно официальному объявлению PHP от 21 октября 2026 года, выпуски 8.5.12, 8.4.27, 8.3.36 и 8.2.35 исправляют две критические уязвимости, которые могут позволить удалённое выполнение кода без аутентификации. Обе получили 9,2 балла по шкале CVSS v4.0, это стандартная оценка того, насколько опасной считается уязвимость. Удалённое выполнение кода означает, что злоумышленник может запускать на сервере команды с правами учётной записи веб-процесса.

Затронута любая установка PHP, обслуживающая веб-запросы: PHP-FPM, mod_php, php-cgi, FrankenPHP и LiteSpeed. Amazon Threat Intelligence написала 21 октября, что её сеть ловушек впервые зафиксировала попытку эксплуатации 17 октября, за четыре дня до публичного раскрытия. SecurityWeek сообщает, что, по словам watchTowr, ходящие в сети доказательства концепции пока не доходят до выполнения кода. Попытки есть, подтверждений успеха немного, и это не повод ждать.

Если ваш сайт работает на PHP, считайте, что он затронут. По данным агентства Anadolu, ФБР оценивает, что PHP используется примерно на 70 % сайтов, а по сведениям CISA он может быть встроен в другое программное обеспечение и оставаться для вас невидимым. Наш инструмент определения технологий даёт снаружи первое представление о том, на чём работает сайт, но не ждите от него точной версии.

Чтобы узнать версию точно, пройдите путь, который описывает WordPress.org: в админ-панели WordPress откройте Инструменты, Здоровье сайта, Информация, Сервер. Панели хостинга обычно тоже её показывают, а для сайтов не на WordPress версию должен назвать ваш разработчик или провайдер. Если она ниже номера вашей линейки (8.2.35, 8.3.36, 8.4.27 или 8.5.12), то, согласно бюллетеням GitHub, вы затронуты.

На виртуальном хостинге сервером управляет провайдер, поэтому ваша задача спросить у него письменно: обновили ли PHP из-за этих уязвимостей и какая версия у меня сейчас? По данным WordPress.org, позиция провайдеров менялась с часа на час: одни уже исправили, другие говорили, что защищены WAF, третьи ещё работали. WAF это межсетевой экран, который фильтрует входящие запросы. Если вам отвечают «вы защищены», уточните, на какую версию вас перевели.

Согласно примечаниям к выпускам cPanel, EasyApache 4 25.91 исправляет обе уязвимости от ea-php74 до ea-php85, а 25.92 заново собирает пакеты ea-php74, ea-php80 и ea-php81. Такие пакеты обычно приходят с автоматическим обновлением, но это наше толкование, поэтому администратору сервера стоит проверить версии в WHM. С Plesk вопрос тот же: попросите у провайдера название пакета и номер версии. Если у вас собственный сервер, то, согласно базе знаний Laravel Forge, автоматические обновления безопасности PHP не исправляют; его нужно обновлять отдельно на каждом сервере. Проект PHP также отмечает, что дистрибутивы Linux получили исправление заранее, и советует «проверить пакеты вашего поставщика».

PHP 8.1 и более ранние версии больше не получают обновлений от проекта PHP. Его команда безопасности подготовила минимальные исправления исходного кода для 7.4, 8.0 и 8.1, а некоторые дистрибутивы тоже переносят исправления в старые версии, но в пакет вашего хостера они могли не попасть. WordPress.org напоминает и о том, что PHP старше 8.2 не получает обновлений безопасности. По данным VulnCheck, насчитали более 2,6 миллиона PHP-серверов, доступных из интернета, и не менее 1 миллиона из них работает на версиях, поддержка которых закончилась.

CISA рекомендует отключать системы, которые нельзя обновить или которые работают на 8.1 и ниже. WordPress.org, ссылаясь на британский NCSC, советует отключить сервер до обновления, если вы управляете им сами. Если сайт не приносит дохода, например простая страница-визитка, это реалистичный вариант. Поддержка PHP 8.2 заканчивается 31 декабря 2026 года, так что переход на 8.2.35 даёт лишь короткую передышку; планируйте путь обновлений уже сейчас.

Объявление PHP однозначно: полное решение даёт только обновление; временные меры уменьшают уязвимость к отдельным путям атаки, но не делают установку безопасной. Бюллетень GitHub тоже называет переход на исправленную версию единственной полной мерой. Вторая уязвимость требует, чтобы два запроса попали в один и тот же процесс; несколько процессов и их перезапуск снижают вероятность успеха, но не убирают риск, а полностью устранить его настройками нельзя. CISA предлагает WAF как временный шаг, и слово «временный» здесь важно.

Ниже меры, которые перечисляет объявление PHP, и применять их должен администратор вашего сервера, а не вы. Объявление упоминает также исправление фатальных ошибок и тайм-аутов, которые может вызвать злоумышленник, и удаление недопустимых или устаревших настроек INI, применяемых к каждому запросу. По данным Codeable, WordPress не использует session.upload_progress; всё же спросите про другие приложения на сервере.

• memory_limit=-1, заданный так, чтобы приложение не могло его переопределить (через php_admin_value)
• Низкий post_max_size: 8M, если загрузки файлов нет, и 32M, если есть, при этом upload_max_filesize должен быть меньше
• session.upload_progress.enabled=0 и перезапуск всех процессов, задаётся в php.ini или в конфигурации пула, а не через ini_set или .user.ini
• fatal_error_backtraces=0 в PHP 8.5
• Не использовать RLIMIT_AS и RLIMIT_DATA, так как они могут вызвать уязвимость

Amazon Threat Intelligence советует начинать расследование как минимум с 17 октября, ведь именно в тот день зафиксирована первая попытка. Признаки такие: POST-запросы к загрузкам форм, содержащие строку PHP_SESSION_UPLOAD_PROGRESS, подозрительные записи в журналах веб-сервера, неожиданная активность процессов или изменения файлов. Попросите провайдера или администратора поискать эти следы. CISA рекомендует также следить за процессами PHP, которые открывают оболочку или скачивают инструменты. Наш инструмент аудита безопасности проверяет базовые настройки, видимые снаружи; он не заменяет журналы и файлы на сервере.

Вторая тема это долгоживущие процессы. Согласно базе знаний Laravel Forge, обновление перезапускает PHP-FPM, но обработчики очередей, Horizon и Octane, запущенные из командной строки, продолжают работать на старом PHP, пока их не перезапустят. Для проверки выполните на сервере php8.4 -v и php-fpm8.4 -v (если используете 8.4); по данным Qualys, версия, которую показывает php -v, может отличаться от установки, обслуживающей веб-запросы. Если вы временно задали memory_limit=-1, верните конечное значение. Если вы нашли следы или не можете быть уверены, обсудите с администратором смену паролей к базе данных, ключей API и паролей администраторов; это общий принцип гигиены, в источниках его нет.

Выделяются три ошибки. Избежать их для большинства компаний так же важно, как само обновление.

Amazon пишет, что окно установки исправлений в 7 или 30 дней предполагает задержку, которой больше нет; измерять нужно в часах. PHP Foundation, в свою очередь, рассказала, что исправление готовили с августа, что 20 октября идентификаторы CVE просочились с неверной информацией и что выпуск перенесли на день раньше. Вывод простой: запишите, кому принадлежит программное обеспечение под вашим сайтом, кто его обновляет и кому звонить, и привяжите к календарю версии, у которых заканчивается срок поддержки.

• Считать, что хватит обновления плагина, темы или WordPress: по данным WordPress.org, для этих проблем обновление WordPress не требуется и не планируется, а обновление плагина или темы вас не защищает
• Доверять php -v: версия в командной строке может отличаться от установки, обслуживающей веб-запросы
• Считать WAF решением: CISA относит его к временным мерам, а слова провайдера «мы защищаем с помощью WAF» не показывают, что версия актуальна