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

Вечером 21 октября 2026 года в PHP — платформе, на которой работают и Битрикс, и WordPress, и большинство интернет-магазинов рунета — закрыли две критические уязвимости: CVE-2026-109618 и CVE-2026-109619. Совместное название — PHP2Shell. Оценка опасности — 9,2 из 10 по CVSS v4.0, и это не «очень плохо», это максимум практического смысла: злоумышленник выполняет свой код на сервере без пароля, без авторизации, без единого клика от вашей стороны.

CISA — американский регулятор кибербезопасности — в тот же день выпустил экстренное предупреждение с требованием патчить немедленно. Когда такое пишет не хостинг-блог, а государственная структура, к вечернему чаю прилагается незапланированный аудит всего серверного парка. Чем я и занялся. Делюсь хронологией — она показательнее любой теории.

Что именно сломано — на пальцах

Обе уязвимости живут в обработке аварийных ситуаций. Первая: когда PHP при разборе входящего запроса упирается в лимит памяти, он «раскручивает» выполнение через longjmp — механизм экстренного выхода. Так вот, после этого выхода внутреннее состояние интерпретатора остаётся частично инициализированным: часть структур помечена как «готовые к работе», хотя реально они не подготовлены. Вторая: при фатальной ошибке глобальные указатели остаются висеть на уже освобождённой памяти (классический use-after-free — с сессиями, кэшем классов OPcache и backtrace’ами). Следующий запрос на том же рабочем процессе подбирает это сломанное состояние — и при определённом стечении обстоятельств атакующий превращает порчу памяти в выполнение своего кода.

Практический вывод, который надо выучить наизусть: авторизация сайта не защищает вообще. Запрос обрабатывается интерпретатором до того, как Битрикс или WordPress начнут проверять хоть какой-то пароль. Сложный админский пароль, двухфакторка, скрытая админка — всё это орнамент на двери, которую вынесли с другой стороны здания.

Под ударом — весь PHP примерно от 5.4 до 8.5 без патчей от 21.10.2026. Патченные версии: 8.2.35 и новее, 8.1.34 и новее, свежие релизы 8.3/8.4/8.5.

Кейс 1: магазин на Битриксе — 20 минут, если знать, где рестартовать

Первым пошёл интернет-магазин кровельных материалов на 1С-Битрикс (mkrovlya.ru — один из моих публичных кейсов). PHP 8.2.34, сервер на BitrixVM. Обновление до 8.2.35 через менеджер пакетов заняло минуты.

И тут — ловушка, о которой стоит знать каждому, кто администрирует Битрикс сам: я отправил перезапуск php-fpm и получил «сервис не найден». На этом сервере php-fpm не был установлен вовсе — PHP работает как модуль Apache (mod_php). Это две разные архитектуры с одинаковым симптомом «сайт на PHP», и перезапускать нужно разное: в одном случае systemctl restart php-fpm, в другом — systemctl restart httpd. Пока сервис не перезапущен, рабочие процессы продолжают крутить в памяти старый, уязвимый код — обновление файлов само по себе ничего не закрывает.

Итог: 8.2.35, Apache перезапущен, все страницы — код 200. Двадцать минут вместе с проверками.

Кейс 2: мёртвая ветка PHP 8.1, у которой неожиданно нашлось будущее

Ветке PHP 8.1 официальная поддержка закончилась в декабре 2025-го. Логика «ветка мёртвая — фиксов не будет» казалась железной. Но Remi Collet, мейнтейнер самого популярного RPM-репозитория PHP для Enterprise Linux, выпустил бэкпорт патча: сборка 8.1.34-6 с прямой записью в changelog — «Avoid state corruption via bailout, CVE-2026-109618, CVE-2026-109619».

Сервер с EOL-веткой обновился до 8.1.34 и закрылся. Урок: даже на «мёртвой» ветке проверяйте репозиторий и changelog, а не доверяйте общей логике. Свежий критический фикс иногда портируют назад — и тогда вам не нужна срочная миграция.

Кейс 3: CentOS 7 — тупик, в который не стоит заходить повторно

Самая неприятная часть вечера: два сервера клиентов на CentOS 7. Операционная система снята с поддержки в 2024-м, и потолок PHP для неё — 8.1.29, сборка июня 2024 года. Сверился с репозиторием автора сборок напрямую: для el7 фикса нет и не будет. Никогда.

Что можно сделать на такой платформе — только частичный митигейшн: memory_limit = -1 убирает самый предсказуемый триггер уязвимости (исчерпание памяти при обработке запроса). Важная деталь для Битрикс-серверов: значение из php.ini перебивает файл bitrixenv.ini из /etc/php.d, а имена ini-файлов в этом каталоге сортируются как строки — файл с именем на цифру загрузится раньше буквенного. Свой оверрайд назвал zz-php2shell-mitigation.ini — грузится последним и выигрывает.

Но называть это «закрыли уязвимость» нельзя — можно лишь «снизили вероятность». Полное решение для CentOS 7 одно: миграция на AlmaLinux 9 или Rocky 9 с PHP 8.2+. Это уже проект на день-два, а не вечер, и делать его нужно до того, как сканеры хакеров досканируются до вашего IP — после публикации такой CVE автоматические обходы рунета стартуют немедленно, эксплойты к подобным вещам появляются за считаные дни.

Четыре пути закрытия — от лучшего к самому последнему

Путь	Кому подходит	Что даёт
Обновление PHP на поддерживаемой ОС	PHP 8.2/8.3/8.4/8.5 на EL8/EL9, Ubuntu/Debian	Полное закрытие, минуты работы
Бэкпорт патча на EOL-ветку 8.1	Серверы на EL8/EL9 с PHP 8.1 (Remi-репозиторий)	Полное закрытие сборкой 8.1.34-6
Митигейшн memory_limit = -1	EOL-платформы, где патча нет вообще	Частичная защита, только как временная мера
Миграция на свежую ОС	CentOS 7 и другие платформы без поддержки	Единственное полное решение для тупика

Отдельная строка для владельцев сайтов на виртуальном хостинге: у вас всё проще. В панели хостинга версия PHP переключается в пару кликов — проверьте, что назначена ветка 8.2 или 8.3, обновлённая после 21 октября. На поддерживаемом хостинге минорные обновления накатывает сам хостер, ваша задача — не сидеть на старой мажорной версии из экономии нервов.

Почему это касается не только «айтишников»

Взломанный сайт — это не только сломанный дизайн. Это база заявок с персональными данными клиентов, за утечку которых с 2025 года штрафуют по 152-ФЗ миллионами — до 15 млн за специальные категории данных, при повторной утечке — процентом от выручки. Это подмена контента: на взломанные сайты с 2022 года вешают запрещённые материалы, после чего сайт уходит в блокировку у всех провайдеров, а владельцу приходится объясняться с проверяющими. Для интернет-магазина или клиники это остановка канала продаж и репутационный шрам одновременно.

Поэтому вопрос «обновлять или пусть висит» — не технический, а финансовый. Обновление PHP — час работы; последствия взлома — недели и суммы с большим количеством нулей.

И немного о том, почему я советую не тащить EOL-хлам в будущее

Вечер с PHP2Shell — отличная рентгенограмма подходов к инфраструктуре. Сервер на поддерживаемой платформе закрылся за 20 минут. Сервер на CentOS 7 не закрылся вообще — и не закроется, сколько ни обновляй.

Именно поэтому я своё сопровождаю так: мониторинг версий, патчи в день релиза, а для новых проектов — связка, где уязвимостей такого класса в принципе нет: наш сайт automata.sale, например, работает на Node.js за nginx, и PHP2Shell к нему неприменим чисто физически. Битрикс я при этом не хороню — он силён в каталоге и админке, и связка «Битрикс как бэкенд + современный фронтенд» снимает с него половину рисков фронта. Но инфраструктурный фундамент — ОС, PHP, сроки поддержки — должен быть живым. Проверить, на чём стоит ваш сайт, и привести это в порядок — ровно та работа, которую мы берём на сопровождении; если узнали в этой статье свой сервер на CentOS 7 — напишите, посчитаем миграцию.

---

📞 +7 (906) 311-77-69 · ✉ hello@automata.sale · 💬 Telegram: @automatasale · 🌐 automata.sale

ИП Урядов Евгений Евгеньевич · ИНН 645112058391 · ОГРНИП 312645301900058 Работаем по России, Беларуси и Казахстану