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

Коротко. 21 октября 2026 года разработчики PHP выпустили экстренные версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают две критические уязвимости, которые назвали PHP2Shell: через них сайт можно взломать одним запросом, без логина и пароля, и выполнить на сервере свой код. Под угрозой почти любой сайт на PHP — WordPress, 1С-Битрикс, OpenCart, Drupal, Joomla, самописные сайты. Попытки атак идут с 17 октября, после выхода исправлений — массово. Что делать: узнать, какая версия PHP работает на сайте, обновить её до исправленной (или получить исправленную сборку от хостинга), перезапустить PHP и проверить сайт на следы взлома.

Статья собрана по объявлению разработчиков PHP и публикациям исследователей на 22 октября 2026 года. Ситуация быстро меняется — будем обновлять материал.

Что такое PHP2Shell

Уязвимости получили номера CVE-2026-109618 и CVE-2026-109619, обе оценены в 9,2 балла из 10 по шкале CVSS 4.0 — это критический уровень. Простыми словами:

• CVE-2026-109618 — ошибка при нехватке памяти. Специально собранный запрос с формой или загрузкой файла заставляет PHP прервать обработку на полпути, а при уборке за собой PHP портит память так, что злоумышленник может выполнить свой код.
• CVE-2026-109619 — ошибка с «остатками» прошлого запроса. После сбоя в одном запросе внутренние данные PHP остаются в памяти, и следующий запрос к тому же процессу может ими воспользоваться. Один из путей идёт через механизм прогресса загрузки файлов, который включён по умолчанию, — сайту даже не нужно работать с сессиями.

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

Уязвимы все способы запуска PHP для сайтов: PHP-FPM, Apache с mod_php, php-cgi, LiteSpeed, FrankenPHP. Разработчики считают самым опасным mod_php: там показан рабочий взлом одним запросом, ещё до того как запустится код самого сайта. Команды PHP в консоли (CLI) уязвимость не затрагивает.

Хронология

Из-за угрозы временно закрывали сайт парламента Нидерландов и государственные порталы MijnOverheid и DigiD, 4chan перевёл сайт в режим «только чтение», по подсчётам ТАСС отключения госресурсов затронули как минимум 13 стран. Публично не подтверждено, что все эти отключения связаны именно с PHP2Shell: многие отключались превентивно.

Какие версии PHP исправлены

Последний пункт важен: на старом PHP номер версии после исправления не меняется. Например, исправленный PHP 7.4 из репозитория Sury по-прежнему показывает 7.4.33. Проверять нужно дату сборки или журнал изменений пакета, а не только номер.

Что делать, если сайт на обычном хостинге

1. Узнайте версию PHP. Она видна в панели хостинга, в разделе настроек сайта или PHP. В WordPress — в «Инструменты → Здоровье сайта → Информация → Сервер», в Битриксе — в «Настройки → Инструменты → Информация о PHP».
2. Спросите хостинг, установлено ли исправление. На виртуальном хостинге PHP обновляет провайдер, и именно он должен подтвердить, что сборка, на которой работает ваш сайт, содержит исправления CVE-2026-109618 и CVE-2026-109619.
3. Если сайт на PHP 8.1 и старше — переключите его на 8.3 или 8.4, если сайт это выдерживает. Проверьте после переключения формы, корзину и оплату. Если не выдерживает — это повод заняться обновлением сайта: старый движок на старом PHP останется уязвимым и к следующим ошибкам.

Что делать, если у вас свой сервер

Обновите PHP из репозитория, откуда он установлен, и перезапустите все процессы PHP: работающие процессы держат старый код в памяти, пока их не перезапустят. Для Debian и Ubuntu:

# какие пакеты PHP стоят и откуда
dpkg -l 'php*' | grep ^ii
apt-cache policy php8.4-fpm

# обновить только PHP, не всю систему
apt update
apt install --only-upgrade $(dpkg -l 'php*' | awk '/^ii/{print $2}')

# перезапустить PHP-FPM, а если сайт на Apache с mod_php — и Apache
systemctl restart 'php*-fpm.service'
systemctl restart apache2

# проверить: в журнале пакета должны быть номера CVE
zgrep -l 'CVE-2026-10961' /usr/share/doc/php*/changelog.Debian.gz

Исправленные пакеты уже вышли:

• Debian 13 — php8.4 версии 8.4.27-1~deb13u1;
• Debian 12 — php8.2 версии 8.2.35-1~deb12u1;
• Ubuntu 24.04 и 22.04 — исправлены с прежними номерами версий;
• репозиторий Sury — все ветки от 5.6 до 8.5, для старых — с прежними номерами версий.

Если сервер под панелью (ISPmanager, HestiaCP, cPanel, Plesk), учтите: панели часто ставят собственные сборки PHP — например, в /opt/php84. Команда apt их может не затронуть, обновлять их нужно средствами панели.

Не запускайте в спешке полное обновление всего сервера. Вместе с PHP обновятся база данных, веб-сервер и библиотеки, и если что-то на сервере перезапускает службы само (мониторинг, автоисправление панели), обновление может зависнуть посередине и уронить сайты. Для этой уязвимости достаточно обновить только PHP.

Если обновить прямо сейчас нельзя

Разработчики PHP дают временные меры. Они снижают риск, но не делают сайт безопасным — полное решение только обновление:

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

Как проверить, не взломали ли сайт

Публичных подтверждённых взломов на 22 октября нет, но попытки идут с 17-го. Признаки, на которые стоит посмотреть:

• новые PHP-файлы в папках сайта, особенно в uploads, upload, tmp, и изменённые .htaccess;
• падения PHP в логах — «Segmentation fault», «SIGSEGV», «exited on signal 11»: так выглядят неудачные попытки эксплуатации;
• посторонние процессы от пользователя сайта: оболочки, майнеры, curl и wget, которые никто не запускал;
• новые администраторы в CMS и незнакомые задания в cron.

# PHP-файлы, изменённые с 17 октября
find /var/www -newerct 2026-10-17 \( -name '*.php' -o -name '.htaccess' \) -not -path '*/cache/*'

# падения PHP
journalctl --since 2026-10-17 | grep -iE 'php.*(segfault|SIGSEGV)'

# процессы от пользователя сайта (подставьте своего)
ps -u www-data -o pid,lstart,args

Если что-то нашлось — не удаляйте файлы сразу: сохраните их и логи для разбора, смените пароли от базы и админки, а лучше восстановите сайт из резервной копии, сделанной до 17 октября, и только потом обновите.

Похожий порядок проверки мы разбирали на примере массового взлома сайтов на 1С-Битрикс в 2022 году. Если сервер стоит у хостинга на VMmanager, проверьте и доступы: в октябре через взлом VMmanager и FirstVDS с клиентских серверов копировали пароли и ключи.

Частые вопросы

Какая версия PHP защищена от PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 и новее. Для PHP 8.1 и старше официальных исправлений нет: их выпускают только дистрибутивы и поставщики пакетов, и номер версии при этом не меняется.

Как узнать, какая версия PHP на сайте?
В панели хостинга, в настройках сайта или PHP. В WordPress — «Инструменты → Здоровье сайта → Информация → Сервер», в 1С-Битрикс — «Настройки → Инструменты → Информация о PHP». Команда php -v в консоли показывает версию консольного PHP, а сайт может работать на другой.

Уязвим ли сайт на WordPress или 1С-Битрикс?
Да, если он работает на неисправленной версии PHP. Ошибка в самом PHP, а не в CMS, поэтому под угрозой WordPress, 1С-Битрикс, OpenCart, Drupal, Joomla и самописные сайты. Обновление CMS и плагинов уязвимость не закрывает — нужно обновить PHP.

Защищает ли Cloudflare от PHP2Shell?
Частично. 21 октября Cloudflare включил правила против известных вариантов атаки на всех тарифах, включая бесплатный. Это временная мера, как и настройки php.ini: они снижают риск, но не делают сайт безопасным. Полное решение — обновить PHP.

Обновил PHP, а номер версии не изменился. Это нормально?
Для PHP 8.1 и старше — да: исправленные сборки дистрибутивов сохраняют прежний номер, например 7.4.33 из репозитория Sury. Проверьте дату сборки или журнал изменений пакета: в нём должны быть CVE-2026-109618 и CVE-2026-109619. После обновления перезапустите все процессы PHP.

Нужно ли что-то делать, если PHP используется только в консоли?
Консольный PHP (CLI) уязвимость не затрагивает. Обновлять нужно PHP, на котором работает сайт: PHP-FPM, Apache с mod_php, php-cgi, LiteSpeed или FrankenPHP.

Что делаем мы

Мы проверяем серверы клиентов на поддержке: какие версии PHP работают на сайтах, есть ли в сборках исправления и нет ли следов атак — падений PHP, новых файлов, посторонних процессов. Где PHP ещё не исправлен — обновляем только PHP, без полного обновления сервера, и перезапускаем.

Если ваш сайт не на нашей поддержке и вы не уверены, что он защищён, — напишите. Проверим версию PHP и сборку, подскажем, как обновиться, и посмотрим, нет ли следов взлома.

Источники

• PHP: объявление о выпуске исправлений и временные меры
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618) и GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• CERT-EU: Critical Vulnerabilities in PHP
• Debian Security Tracker
• Amazon: эксплуатация до публикации
• Rapid7: технические подробности
• SecurityLab: две дыры в PHP заставили отключать сайты
• Хабр: критическая уязвимость в PHP