PHP2Shell: как мы закрывали уязвимость PHP на хостинге

21 октября в 17:00 по Москве PHP выпустил исправления сразу для двух критических уязвимостей. Исследователи назвали их PHP2Shell: через них можно выполнить свой код на сервере, отправив сайту специально собранный запрос. Затронуты все версии PHP, начиная с 5.4 (2012 год).

Если ваш сайт на хостинге Siteko, делать ничего не нужно: 22 октября мы обновили PHP на всех серверах. Ниже рассказываем, что это за уязвимость, как мы её закрывали, о чём при этом легко забыть и что проверить, если сайт живёт на своём сервере.

Что за уязвимость

Обе ошибки, CVE-2026-109618 и CVE-2026-109619, сидят в механизме, который показывает прогресс загрузки файла (session upload progress). Он включён в PHP по умолчанию, поэтому уязвима обычная установка без всяких особых настроек. Оценка опасности 9.2 из 10.

Готовые эксплойты из открытого доступа, по данным Sansec, на стандартной установке пока не срабатывают: им нужна ещё одна ошибка в самом сайте или точно подобранная сборка PHP. Но код уже публичный, и ждать, пока его доработают, никто не стал.

Исправленные версии: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для PHP 8.1 и старше официальных релизов не будет: эти ветки больше не поддерживаются. Команда PHP выложила исправления в исходниках для 7.4, 8.0 и 8.1, а дальше всё зависит от того, кто собирает вам PHP: дистрибутив, панель или хостинг.

Временная мера, которую советовали все, кто разбирал уязвимость: строка в php.ini:

session.upload_progress.enabled = Off

Она закрывает основной путь атаки, но не единственный. Обновление всё равно нужно.

Хронология

Новость пошла раньше, чем исправления и официальные письма. Всё время по Москве:

• 17 октября: Amazon видит первую попытку атаки через эту ошибку;
• 20 октября: подробности утекают до запланированного раскрытия, исследователи watchTowr подтверждают, что код действительно выполняется;
• 21 октября, 10:43: Cloudflare сообщает о первых атаках, патча ещё нет;
• 21 октября, 17:00: PHP выпускает исправленные версии;
• 22 октября, 18:07: обновлён наш сервер, на котором работает сам Siteko;
• 22 октября, 18:32: обновлены все версии PHP на сервере хостинга;
• 23 октября: закрыли PHP, который живёт не в сайтах: в веб-почте и в панели управления (об этом ниже).

Официальное уведомление об уязвимости пришло к нам через дата-центр, когда всё уже было закрыто. Это не упрёк: рассылка идёт по цепочке, и каждое звено добавляет время. Но вывод для себя мы сделали простой. Если ждать письма, окажешься позади тех, кто читает новости по безопасности. Поэтому следим за ними сами.

Что мы сделали на хостинге

На хостинге у каждого сайта своя версия PHP, от 5.2 до 8.5, и обновлять приходится все сразу: старый сайт на PHP 5.6 уязвим так же, как новый на 8.4. Хостинг работает на CloudLinux, и его разработчики перенесли исправление во все свои сборки PHP, включая давно не поддерживаемые. Пакеты вышли 21 октября, на следующий день мы их поставили.

Для клиентов хостинга всё прошло незаметно: версия PHP сайта осталась той же, перезагружать ничего не пришлось.

Почему phpinfo показывает «уязвимую» версию

Здесь легко запутаться. После обновления phpinfo() на нашем хостинге показывает, например, 8.4.26, хотя исправлена уязвимость в 8.4.27. Так и задумано: CloudLinux не повышает номер версии, а вносит патч в ту же сборку. Проверить, что исправление на месте, можно только по истории изменений пакета:

rpm -q --changelog alt-php84-cli | grep 109618

То же бывает у Debian, Ubuntu и других дистрибутивов, которые переносят исправления в старые версии. Если сканер безопасности ругается на «PHP 8.4.26», это ещё не значит, что сервер уязвим. Но и успокаиваться по номеру версии нельзя: проверять нужно changelog.

PHP, о котором легко забыть

С сайтами клиентов всё решилось установкой пакетов. Больше времени ушло на PHP, который живёт не в сайтах.

Веб-почта. Интерфейс почты в браузере написан на PHP и работает в своём контейнере со своей версией. Её мы обновили отдельно, 23 октября: версия 8.3.15 сменилась на 8.3.36.

Панель управления хостингом. У панели свой PHP, через него работает, например, веб-клиент почты Roundcube. Исправленной сборки от разработчиков панели на тот момент не было. Пришлось закрыть уязвимость временной мерой: тот самый session.upload_progress.enabled = Off в её настройках. Когда выйдет обновление панели, поставим его и уберём заплатку.

Если у вас свой сервер, составьте такой же список. PHP часто стоит в нескольких местах сразу: в системе, в панели, в контейнерах с веб-почтой или phpMyAdmin, иногда внутри самого приложения.

Что нашлось, пока проверяли

После обновления мы проверили файлы сайтов на хостинге и нашли веб-шеллы, то есть чужие скрипты для управления сайтом, на трёх сайтах клиентов. К PHP2Shell они отношения не имели: файлы появились раньше, в июле и 18 октября. Взломщики вошли через дыры в плагинах CMS.

Эти сайты мы приостановили, а владельцам написали, что нашли и что нужно вычистить. Мораль неприятная, но полезная: исправленный PHP не лечит сайт, который взломали раньше. Если сайт давно не обновлялся, проверьте его.

Если сайт на своём сервере или VDS

1. Обновите PHP до 8.5.12, 8.4.27, 8.3.36 или 8.2.35, либо поставьте пакет своего дистрибутива, вышедший после 21 октября. На Debian и Ubuntu обычно хватает apt update && apt upgrade.
2. Перезапустите PHP-FPM или веб-сервер, иначе старый код останется в памяти работающих процессов.
3. Найдите остальной PHP на сервере: панель, веб-почта, phpMyAdmin, контейнеры.
4. Если обновиться сразу нельзя, выключите session.upload_progress.enabled в php.ini каждой версии и обновитесь при первой возможности.
5. Если сайт работает на PHP 8.1 или старше, планируйте переход на новую ветку: исправления для старых веток будут только от дистрибутивов, и не всегда.
6. Проверьте папки сайтов на незнакомые .php-файлы, особенно в uploads, images и cache.

Клиентам, которые арендуют у нас VDS и администрируют его сами, мы разослали эту инструкцию и предложили обновить PHP за них.

Как это устроено на Siteko. На хостинге обновления PHP и системы ставим мы: клиенту не нужно следить за уязвимостями и перезапускать процессы. Если на сайте появилось что-то странное (незнакомые файлы, редиректы на чужие сайты, жалобы на спам), напишите в поддержку, посмотрим. На VDS сервером управляете вы, но обновить PHP или проверить сервер можно попросить нас.

Подробные разборы уязвимости: Sansec, Upwind, Mattias Geniar (на английском).