21 октября 2026 года PHP выпустил экстренные версии безопасности 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают две уязвимости, за которыми закрепилось название PHP2Shell: CVE-2026-109618 и CVE-2026-109619. У обеих оценка CVSS 9,2, и обе позволяют неавторизованному злоумышленнику выполнить на сервере свой код.
От обычной уязвимости в плагине эта отличается одной неприятной деталью. Удалять нечего. Проблема в самом языке, на котором работает ваш сайт, и неважно, WordPress это, Laravel или что-то написанное на заказ.
Что именно сломалось
Обрабатывая запрос, PHP следит за тем, сколько у него памяти. Когда она заканчивается, он бросает начатую работу, перепрыгивая в другое место кода (функция longjmp), и принимается за уборку. Беда в том, что к этому моменту часть данных подготовлена лишь наполовину. Уборка читает оставшиеся в памяти байты там, где должно быть корректное значение. А тот, кто умеет вызывать нехватку памяти по команде, может влиять на то, что в этих байтах окажется.
Вторая уязвимость из той же семьи. После фатальной ошибки в процессе, который обслуживает запросы, остаётся кусок старого состояния. Следующий посетитель попадает на сервер, который помнит чужой запрос и лезет в уже освобождённую память.
Результат в обоих случаях один: веб-шелл. Скрипт, через который злоумышленник управляет сервером так, будто сидит за ним.
Кого это касается
Практически всех, у кого PHP-сайт работает на необновлённой версии. Уязвимо всё, что старше 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Способ запуска роли не играет: затронуты Apache с mod_php, PHP-FPM, php-cgi, LiteSpeed и FrankenPHP. Причём в конфигурации по умолчанию, включать что-то необычное не требуется.
Если вы ещё на 7.4, 8.0 или 8.1, официальной поддержки у этих веток нет, но бэкпорты исправления существуют. Считайте это хорошим поводом запланировать обновление, потому что в следующий раз может так не повезти.
О масштабе: Cortex Xpanse от Palo Alto насчитал больше 22 миллионов публично доступных экземпляров PHP, которые могли быть уязвимы. Это не число взломанных сайтов, а число дверей, в которые можно было постучаться. 26 октября CISA внесла обе уязвимости в каталог активно эксплуатируемых.
Одно уточнение, потому что в первые дни вокруг таких новостей много путаницы. Unit 42 сначала описала атаку на европейское государственное ведомство как возможное следствие PHP2Shell, а 25 октября отозвала это заявление: связь подтвердить не удалось. На срочности обновления это не сказывается никак.
Что мы сделали для клиентов
Сайты, которые мы ведём, работают на управляемом хостинге, где PHP обновляется централизованно. Это удобно, но верить странице статуса провайдера на слово нам показалось мало. Мы прошли по проектам один за другим, проверили версию, которую реально отдаёт сервер (а не ту, что показывает админка), и просмотрели логи за дни вокруг 21 октября. Ничего подозрительного не нашли.
Клиенты с ежемесячной поддержкой об этом чаще всего даже не узнали, потому что именно за это там и платят. Остальным мы написали.
Как проверить самому
Пять минут, не больше.
- В панели хостинга (cPanel, Plesk или собственная панель) найдите настройку версии PHP. Нужен полный номер. «PHP 8.3» не годится: разница между 8.3.35 и 8.3.36 – это ровно то, о чём статья.
- В WordPress тот же номер лежит в разделе Инструменты → Здоровье сайта → Информация → Сервер.
- Задайте хостингу один вопрос: на какой версии PHP работает мой сайт и когда вы выкатили исправление CVE-2026-109618? Ответ в духе «вы защищены» без номера версии, на наш взгляд, не считается.
А через два дня нашлась третья
23 октября PHP сообщил ещё об одном пути к выполнению кода, CVE-2026-115560. Патча пока нет, он выйдет в обычном багфикс-релизе. Для эксплуатации нужна довольно редкая комбинация настроек: session.serialize_handler должен быть выставлен в php_binary или php_serialize, приложение должно переключить его на php во время выполнения через ini_set() до вызова session_start(), и при этом должен быть включён session.upload_progress.enabled. В команде PHP считают такое сочетание почти не встречающимся на практике.
Рекомендованная защита – отключить отслеживание прогресса загрузки, то есть session.upload_progress.enabled=0 в php.ini или в конфигурации пула FPM. У тех, кто оставил его выключенным после 21 октября, этот путь уже закрыт.
Если обновиться прямо сейчас нельзя
Чинит это только патч. Datadog в своём разборе пишет прямо, и мы согласны: настройками php.ini отделаться не получится. Пока вы ждёте хостинг, имеет смысл ограничить доступ к приложению снаружи и следить за такими следами:
- ошибки нехватки памяти со странным «Unknown on line 0» в логе
- необычно большие отправленные формы с полями
PHPSESSIDилиPHP_SESSION_UPLOAD_PROGRESS, либо сотни частей формы в одном небольшом запросе - падающие воркеры и segmentation fault в логе сервера
- процесс shell, запущенный веб-процессом, самый надёжный признак из всего списка
Если что-то нашли, не удаляйте вслепую. Позовите разработчика или хостинг и рассчитывайте на восстановление из чистой резервной копии и смену паролей.
Не уверены, что с сайтом всё в порядке? Мы проверим его в рамках аудита безопасности.