21 октября 2026 года команда PHP выпустила исправления для двух критических уязвимостей, которые получили общее имя PHP2Shell. Обе связаны с удалённым выполнением кода и оценены в 9,2 балла из 10 по CVSS 4.0. Проблемы затрагивают PHP 5.4 и новее, а значит — WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel и тысячи самописных лендингов.
Хорошая новость: массового червя, как в случае Log4Shell, пока нет. Публичные эксплойты не срабатывают против дефолтной установки PHP, а для атаки нужны определённые условия на сервере. Плохая: попытки эксплуатации фиксировали ещё до официального релиза патчей, поэтому откладывать обновление всё равно нельзя.
- Что: две критические RCE-уязвимости в PHP.
- Кого касается: PHP 5.4+, WordPress, CMS, лендинги, PBN, самописные сайты.
- Что делать: обновиться до 8.2.35, 8.3.36, 8.4.27 или 8.5.12.
- Если не обновиться: временно закрыть `multipart/form-data` и включить WAF.
Что нашли
Уязвимости получили номера CVE-2026-109618 и CVE-2026-109619. Обе — use-after-free в движке PHP. При фатальной ошибке, чаще всего при выходе за `memory_limit`, PHP прерывает обработку запроса, но не всегда корректно очищает память. Следующий запрос или переиспользованный воркер может принять освобождённую память за живые данные.
Первая уязвимость связана с обработчиком прогресса загрузки файлов (upload progress). Она позволяет не только выполнить код, но и вернуть часть памяти сервера в ответе — потенциально с паролями, токенами, API-ключами и даже TLS-ключами из других запросов. Вторая — с обработкой фатальных ошибок и OPcache: через неё также можно добиться RCE.
Атака начинается с запроса `multipart/form-data` — того же формата, который браузер использует для загрузки файлов. PHP разбирает тело запроса до того, как выполнится код сайта, поэтому уязвимы и приложения, в коде которых ошибок нет.
Кого это касается
Проблема в самом PHP, а не в конкретной CMS. Исследователи Sansec перечислили затронутые приложения: Magento 2.4.9, WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 и WHMCS.
Для арбитражных команд это особенно неприятно по трём причинам:
- Лендинги. Старые промо-страницы часто живут на WordPress или самописном PHP и годами не обновляются.
- PBN и сетки сайтов. Чем больше проектов, тем выше шанс, что какой-то сервер забыли обновить.
- Платный трафик. Если лендинг взломали и подменили редирект, бюджет продолжает уходить, а конверсий нет.
Какие версии безопасны
| Ветка | Безопасная версия |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 и старше | Официальных патчей нет, только бэкпорты от дистрибутивов |
PHP 8.1 и более старые ветки уже не поддерживаются. Для них патчи выпускают поставщики серверного ПО: Ubuntu, Debian, Remi, CloudLinux, AlmaLinux и другие. Официальный Docker-образ `php` для 8.1 и старше исправлений не получит — там нужен переход на актуальную ветку.
Как проверить версию PHP
- Панель хостинга. В cPanel, Plesk, DirectAdmin версия PHP обычно видна в разделе настроек сайта или домена.
- Командная строка. `php -v` покажет версию CLI, но не обязательно версию PHP-FPM/Apache. Проверяйте именно тот SAPI, который обслуживает сайт.
- phpinfo(). Временный файл с `phpinfo()` покажет версию и настройки, но не оставляйте его в открытом доступе.
- WordPress. «Инструменты → Здоровье сайта → Информация» показывает версию PHP, которую видит WordPress.
- Поддержка хостинга. Самый надёжный вариант: попросить подтвердить, что пакет обновлён и содержит CVE-2026-109618.
Обновление WordPress, Drupal или плагинов само по себе не обновляет PHP на сервере. Это разные вещи.
Что делать
- Сделайте бэкап сайта и базы данных перед обновлением.
- Обновите PHP до безопасной версии через панель хостинга или пакетный менеджер.
- Перезапустите PHP-FPM или Apache — без рестарта воркеры могут продолжить работать со старым кодом.
- Проверьте сайт: формы, загрузку файлов, админку, оплату, основные редиректы.
- Проверьте SAPI. Если используется Apache + mod_php, обновление PHP-FPM может не исправить ситуацию. Уточните, какой обработчик реально обслуживает сайт.
- Включите WAF и проверьте логи на подозрительные `multipart/form-data` запросы.
- Обновите не только основной сайт, но и старые лендинги, тестовые домены и PBN.
Если обновиться прямо сейчас нельзя
Это временные меры, а не замена патчу. Они покупают время, но не закрывают проблему полностью.
- Заблокируйте `multipart/form-data` на уровне nginx или Apache. Это ломает загрузку файлов и может сломать оформление заказа — обязательно протестируйте.
- Отключите `session.upload_progress.enabled` в php.ini или пуле PHP-FPM. Само по себе это не полная защита, но снижает поверхность атаки.
- Поставьте WAF-правила. AWS, Cloudflare и другие вендоры уже выпустили сигнатуры; уточните у своего провайдера.
- Ограничьте доступ к админкам по IP и включите двухфакторную аутентификацию.
- Следите за памятью. Некоторые временные митигации советуют `memory_limit = -1`, но это позволяет одному запросу съесть всю память сервера. Не оставляйте так надолго.
Если сайт уже взломали
- Остановите платный трафик на подозрительный лендинг, чтобы не сжигать бюджет.
- Проверьте редиректы, `index.php`, `.htaccess`, загруженные файлы и cron-задачи.
- Смените пароли, API-ключи, токены и ключи SSH.
- Проверьте, не добавлены ли новые пользователи-админы и не изменены ли DNS-записи.
- Восстановите сайт из чистой резервной копии и обновите PHP до патча.
- Проверьте домен в Google Safe Browsing и уведомите хостера.
Почему это критично для арбитража
Взлом лендинга — это не только «сайт лежит». Через уязвимость могут подменить редирект, вставить скрытую рекламу, украсть данные форм или использовать сервер для рассылки. Если на страницу идёт платный трафик, вы теряете бюджет и доверие партнёров, а кабинет может получить жалобы и ограничения.
Особенно внимательно стоит проверить проекты, которые давно не обслуживались: старые PBN, тестовые домены, лендинги под уже закрытые кампании. Они часто остаются в интернете и продолжают быть точкой входа.
FAQ
Что такое PHP2Shell?
Это общее имя для двух критических уязвимостей PHP — CVE-2026-109618 и CVE-2026-109619. Обе позволяют удалённо выполнить код при определённых условиях.
Насколько всё плохо?
CVSS 9,2 — критический уровень. Но массового червя, как у Log4Shell, пока нет: публичные эксплойты не работают против дефолтной установки, нужны специфические условия на сервере.
Какие версии PHP обновить?
8.5.12, 8.4.27, 8.3.36 или 8.2.35. Если у вас 8.1 или старше — ставьте бэкпорт от дистрибутива или переходите на поддерживаемую ветку.
Достаточно ли обновить WordPress?
Нет. Уязвимость находится в PHP, а не в WordPress. Нужно обновить именно версию PHP на сервере.
Нужно ли выключать сайт?
Sansec не рекомендует. Обновление PHP — достаточная мера. Выключать сайт стоит только при подтверждённом взломе или если вы не можете обновиться и хотите переждать.
Можно ли защититься только WAF?
WAF — временная мера. Патч всё равно нужен: сигнатуры могут не покрывать все варианты атаки.
Что делать со старыми лендингами на PHP 7.4?
Искать бэкпорт у хостинга или дистрибутива. Если его нет — переносить на PHP 8.2+ или выводить из эксплуатации.
Как понять, что сайт уже скомпрометирован?
Проверьте редиректы, новые файлы и админов, изменения в `.htaccess`, DNS и cron. Если на лендинге появились скрытые ссылки или незнакомые скрипты — считайте, что взлом возможен.
Источники
Технический разбор: Sansec — PHP2Shell. Официальные релизы: PHP.net. CVE: CVE-2026-109618, CVE-2026-109619. WAF-правила: AWS Security Bulletin. Хронология: watchTowr.