PHP2Shell (CVE-2026-109618 и 109619) на WordPress, Joomla и OpenCart: обновлять нужно PHP, а не плагины

На 21 октября 2026 две критические уязвимости PHP (CVE-2026-109618 и CVE-2026-109619) затрагивают сайты на WordPress, Joomla, OpenCart, Drupal, MODX и Laravel: ошибка в интерпретаторе, а не в плагинах. Нужно обновить PHP до 8.2.35, 8.3.36, 8.4.27 или 8.5.12; для 8.1 и старше исправления нет. Ниже — как узнать версию из админки, что делать на shared-хостинге и как проверить сайт после обновления. Статус хостеров и вендоров проверяйте заново.

PHP2Shell на 21 октября 2026: что известно и почему плагины не спасают

Сегодня, 21 октября 2026, опубликованы две критические уязвимости в самом ядре PHP — CVE-2026-109618 и CVE-2026-109619, обе с оценкой CVSS v4.0 9,2. Они не в WordPress, не в Joomla и не в OpenCart, а в интерпретаторе, на котором эти системы работают. Исправления вышли в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35; для ветки 8.1 и старше официального исправления нет, она вышла из поддержки. Обстановка меняется по часам, поэтому проверьте заново страницы вендоров и хостера в день, когда будете читать статью. Общий порядок действий на первый час мы разобрали в статье «PHP2Shell CVE-2026-109618 и 109619: что делать за час», здесь — только то, что касается сайтов на CMS.

Главная мысль для владельца сайта: обновлять нужно PHP, а не плагины. Специалисты Sansec подтвердили выполнение произвольного кода без логина на свежих версиях WordPress 7.1.2, Joomla 6.1.4, Drupal 11.4.3 и Laravel 13.11, то есть на актуальных CMS и фреймворках без каких-либо уязвимых модулей. Ошибка срабатывает до того, как управление получает код сайта: PHP разбирает тело запроса multipart/form-data раньше любого плагина. Поэтому «обновили все плагины», «поставили плагин безопасности» и «включили режим обслуживания» не закрывают дыру. Режим обслуживания WordPress тоже не помогает: запрос уже разобран.

Что именно делает уязвимость, если говорить без терминов. Запрос с особым телом заставляет PHP исчерпать память и аварийно прервать работу, оставив внутренние данные запроса в полуготовом состоянии. Следующий запрос на том же рабочем процессе может прочитать остатки чужой памяти: по описанию Sansec, это пароли, токены сессий, ключи API и приватные ключи TLS. Второй вариант ведёт к выполнению кода на сервере. Эксплойт и разборы опубликованы, Sansec ожидает массовую эксплуатацию, а по телеметрии Patchstack на 13:57 UTC подтверждённых взломов ещё не было, только зондирование. Не ждите, пока это изменится.

Конфигурация по умолчанию уязвима, затронуты mod_php, PHP-FPM, php-cgi, FrankenPHP и LiteSpeed. Для сайта агентства недвижимости, интернет-магазина или корпоративной страницы это значит одно: версию PHP надо найти и поднять. Дальше разберём, где её увидеть в админке, какие версии CMS поддерживают, что делать на shared-хостинге и как проверить результат.

Как узнать версию PHP из админки CMS

Начинаем с инвентаризации: на каждом сайте нужно записать версию PHP, способ её подключения (mod_php, PHP-FPM, LiteSpeed) и того, кто за неё отвечает — вы или хостер. Если у компании несколько сайтов, часто всплывает забытый: старая промо-страница, каталог объектов, лендинг прошлой кампании. Для инвентаризации удобен общий реестр, мы описывали подход в статье «инвентаризация IT-активов в компании», сайты и их версии PHP стоит вносить туда же.

Таблица ниже показывает, где в админке увидеть версию PHP. Для WordPress путь подтверждён документацией: Инструменты → Здоровье сайта → вкладка «Информация» → раздел «Сервер». Для Joomla это пункт «Информация о системе» в меню «Система». Для остальных систем мы перечисляем практичные способы, а не гарантированные пункты меню — названия зависят от версии и локализации.

Если доступа в админку нет, а есть SSH, версия видна из консоли. Важно понимать, что консольный PHP и PHP, который обслуживает сайт, могут отличаться: на сервере часто стоит несколько версий. Поэтому надёжнее смотреть версию той службы, которая отвечает за сайт, или страницу диагностики самой CMS.

php -v
wp core version   # если установлен WP-CLI
php artisan about   # Laravel, из каталога проекта

Для WordPress есть удобная возможность: в разделе «Информация» кнопка копирования выгружает все сведения о сайте в буфер. Эту выгрузку можно приложить к заявке хостеру, чтобы не объяснять на пальцах, какая версия стоит и какие расширения подключены. Не публикуйте её в открытых чатах: в ней есть пути и список плагинов.

Совместимость CMS с версиями PHP: что можно ставить

Исправления выпущены для четырёх веток: 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Задача — подобрать самую свежую ветку, которую поддерживает ваша CMS и все её расширения. Данные ниже взяты из официальных требований на 21 октября 2026: WordPress 7.1 и Joomla 6.x. Для OpenCart мы нашли только общее требование документации. По Drupal, MODX и Laravel версии не приводим: смотрите требования вашей конкретной версии на сайте вендора.

Из таблицы видно главное: у WordPress запас широкий, поэтому переход на 8.3 или 8.4 обычно решается переключением версии и проверкой плагинов. Joomla 6 уже требует 8.3 и выше, так что там вопрос только в том, обновлён ли пакет до 8.3.36 или 8.4.27. Сложнее с OpenCart и старыми сборками: нижняя граница PHP 8.0 лежит в зоне без исправления, а совместимость конкретных версий магазина и модулей с PHP 8.2 и выше нужно проверять на копии, а не на боевом сайте.

Отдельная проблема — сайты на старых версиях CMS, которые не поддерживают современный PHP. Например, магазин на OpenCart 2.x или 3.x, написанный под PHP 7. Для PHP 7.4 и старше на Debian и Ubuntu исправления бывают только в платной поддержке (Ubuntu Pro) или в сборках из исходников; по Debian 11 исправления для PHP 7.4 нет. Остаются три пути: обновить CMS до версии, которая работает на поддерживаемом PHP; закрыть сайт за ограничениями из раздела про временные меры; или вывести его из эксплуатации. Решение принимает владелец, мы готовим сравнение вариантов.

Версию PHP, которую вы выбрали, нужно сопоставить с вашим окружением: на Debian и Ubuntu нужные пакеты ставятся по инструкции из статьи «PHP2Shell на Debian и Ubuntu: обновление через Sury и PPA», а если сайт живёт в панели с несколькими версиями PHP, ищите ответ в статье «панели HestiaCP и ISPmanager с несколькими версиями PHP».

Резервные копии перед обновлением и что делать на shared-хостинге

Перед любым переключением PHP делаем две копии: файлы сайта и базу данных. Копия, которая лежит на том же сервере и хранится на том же аккаунте, защищает от ошибки обновления, но не от взлома. Нужна ещё одна копия на отдельном носителе или в другом хранилище, с проверкой, что её можно развернуть. Мы проверяем восстановление на тестовой площадке: пустая копия, которая не открывается, нашей работы не заменяет. Снимок виртуальной машины, если сайт на своём сервере, тоже делаем, но он не заменяет копию базы.

mysqldump --single-transaction -u USER -p DBNAME > site-db-$(date +%F).sql
tar -czf site-files-$(date +%F).tar.gz /path/to/site

На shared-хостинге порядок другой, потому что вы не управляете сервером. Первый шаг — открыть панель хостинга и найти раздел выбора версии PHP. Во многих панелях он называется «Версия PHP», «Настройки PHP» или «Выбор версии»; точное название зависит от хостера. Если там уже есть исправленная ветка (8.2.35, 8.3.36, 8.4.27 или 8.5.12), переключайте сайт на неё после копии и проверки на тестовом поддомене. Если в списке только 7.4, 8.0 или 8.1, пишите хостеру.

Письмо хостеру должно быть коротким и конкретным. Мы в таких случаях отправляем текст в таком виде: «Просим сообщить, обновлены ли версии PHP на серверах до исправленных по CVE-2026-109618 и CVE-2026-109619 (PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12), на каком сроке и как проверить версию для нашего аккаунта. Если исправлений для нашей версии нет, просим включить для нас более новую ветку». Ответ сохраняем: если хостер молчит, это основание для переезда или временных мер.

Отдельно спросите, как у хостера включена защита: стоит ли на их стороне правило, которое режет подозрительные multipart-запросы, и перезапускает ли хостер рабочие процессы PHP после обновления. Статус заявлений конкретных хостеров на 21 октября мы не проверяли и ничего за них не утверждаем, ответ ищите на их странице новостей или в тикете. Если у вас свой сервер или VPS, переходите к инструкциям по ОС: для CentOS, RHEL, Alma и Rocky — «PHP2Shell на CentOS 7, RHEL, Alma и Rocky: Remi и EOL», для сайтов в контейнерах — «образы Docker, PHP-FPM и Nextcloud».

Если обновить PHP сразу нельзя: WAF, Cloudflare и блок multipart

Бывает, что хостер отвечает через несколько дней, а плагин или тема не работает на новой ветке. Тогда нужны временные меры. Подчеркнём: они частичные и не заменяют обновление. Gina Peter Banyard из команды PHP прямо говорит, что надёжных обходных мер нет, единственное исправление — патч. Всё, что описано ниже, только снижает риск, пока вы готовите переход.

Cloudflare выкатил аварийные правила WAF и включил их во всех тарифах, включая бесплатный. Они работают только тогда, когда сервер-источник принимает трафик исключительно от Cloudflare: если сайт открыт напрямую по IP, защиту легко обойти. Проверьте это в настройках фаервола сервера или попросите хостера ограничить доступ. Sansec Shield утечку и выполнение кода не закрывает, поэтому полагаться на него одного нельзя. Cloudflare называет эти правила временной мерой, и мы относимся к ним так же.

Самая жёсткая мера — блок запросов multipart/form-data на веб-сервере, предложенный Sansec. Для nginx это правило в блоке server или location, для Apache — условие и правило перезаписи. После изменения проверяем конфигурацию и перезагружаем веб-сервер. Если сайт на shared-хостинге, править конфигурацию вы не можете, обращайтесь к хостеру.

if ($http_content_type ~* "multipart/form-data") { return 403; }

RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

Блок режет любые загрузки файлов, и это надо понимать заранее. В таблице — что ломается на типичном сайте на WordPress или OpenCart, и что с этим делать.

Дополнительные меры по рекомендациям Patchstack и Sansec: отключить session.upload_progress.enabled в php.ini или конфигурации пула PHP-FPM (не через ini_set и не через .user.ini), сократить post_max_size и upload_max_filesize, ограничить размер запроса и число полей на веб-сервере и перезапустить все рабочие процессы. Параметр memory_limit = -1 предлагает Sansec, но это риск: один запрос может съесть всю память сервера, поэтому нужен контроль памяти. Эти настройки частичные, и по Banyard одного отключения upload progress мало.

Если и временные меры невозможны, NCSC рекомендует рассмотреть отключение системы: сайт-визитку на устаревшей версии лучше выключить или заменить статической страницей, чем оставить открытым. Для сайтов, которые не принимают заявки, часто подходит и пропуск только запросов GET и HEAD.

Как проверить сайт после обновления PHP: сайт, cron, плагины, логи

Переключили версию, но работа не закончена. Первое — убедиться, что сайт действительно работает на новой версии, а не на старом процессе. На своём сервере нужно перезапустить службу: для PHP-FPM — systemctl restart php8.3-fpm (имя зависит от версии), для mod_php — restart apache2 или httpd, потому что reload и graceful недостаточно. Подробности по проверке процессов, которые остались на старой версии, приведены в статье «как найти следы эксплуатации в логах nginx и Apache».

Проверка сайта идёт по списку. Откройте главную и несколько внутренних страниц, проверьте админку, авторизацию, поиск по объектам. Отправьте тестовую заявку с каждой формы и убедитесь, что письмо пришло. Если у вас интернет-магазин на WooCommerce или OpenCart, оформите тестовый заказ до оплаты и, если возможно, проверьте оплату в тестовом режиме. Загрузите картинку в медиабиблиотеку и убедитесь, что она отображается: так проверяется работа расширений GD или Imagick.

Задания по расписанию часто остаются без внимания и ломаются тихо. В WordPress события планировщика видны через WP-CLI, а в Joomla, OpenCart и Laravel расписание обычно настроено на уровне сервера: проверьте, что запись cron существует и выполняется нужным интерпретатором.

wp cron event list
crontab -l
php -v

Дальше — плагины и расширения. В WordPress откройте Здоровье сайта → Состояние и посмотрите критические замечания; после смены версии там могут появиться сообщения об отсутствующих модулях PHP. Если админка выдаёт ошибку, отключите плагины по одному или переименуйте каталог plugins по SFTP и вернитесь к проблемному расширению. В Joomla проверьте раздел «Информация о системе» и отчёт о состоянии расширений; в OpenCart откройте журнал ошибок в разделе обслуживания (проверьте название пункта в вашей версии).

Логи — отдельный шаг. Смотрим журнал ошибок PHP и веб-сервера на предупреждения об устаревших функциях (deprecated), отсутствующих расширениях и ошибках памяти. Пока ведётся наблюдение, обращайте внимание на то, что Patchstack называет косвенными признаками: необычные multipart-запросы с последующей ошибкой memory_limit, повторяющиеся HTTP 500, аномально большие или битые значения PHPSESSID, необъяснимые перезапуски рабочих процессов. Ни один из признаков не доказывает взлом, но и отсутствие признаков не доказывает чистоту.

Если признаки есть, поступаем по принятому у нас порядку: обновляем PHP, считаем сервер возможно скомпрометированным и передаём владельцу список ключей и паролей на ротацию — доступы к базе, ключи API, секретные ключи CMS. Сами пароли живых учётных записей мы не меняем, решение о смене принимает владелец. Если вы ведёте WordPress, помните, что в wp-config.php лежат пароль базы и ключи солей: они входят в этот список.

Типичные ошибки и мини-кейс агентства недвижимости

Представим условную компанию — агентство недвижимости «Новый Адрес» на 12 рабочих мест. Сайт на WordPress с каталогом объектов, форма заявки на показ с загрузкой документов, интеграция с CRM и один забытый лендинг на старой версии OpenCart для продажи услуг. Размещение у сторонних хостеров, админа нет. Подход, который мы предлагаем в такой ситуации: сначала инвентаризация всех сайтов и версий PHP, затем копии, затем переключение там, где хостер даёт исправленную ветку, и временные меры там, где не даёт. Это описание ситуации и подхода, а не отчёт о результатах.

В этой компании мы бы по порядку выполнили следующее: нашли версию PHP через Здоровье сайта у WordPress и у хостера для остального; записали сроки ответов хостера; для лендинга на старом OpenCart предложили варианты — переезд на поддерживаемую версию PHP, перенос в статический вид или отключение. Форму заявки на показ мы бы проверили отдельно, потому что она использует multipart и пострадала бы от блока. Решение по сайту, который нельзя обновить, принимает руководство агентства.

Типичные ошибки, которые мы видим на практике, собраны в списке ниже. Каждую из них нужно исключить до закрытия задачи, иначе сайт остаётся уязвимым или перестаёт принимать заявки.

• Обновить плагины и считать вопрос закрытым — PHP2Shell находится в интерпретаторе.
• Не перезапустить PHP после обновления пакета: старый процесс продолжает работать на уязвимой версии.
• Оставить сайт на PHP 7.4, 8.0 или 8.1 без исправления, потому что «WordPress поддерживает».
• Включить блок multipart и не проверить формы, оформление заказа и загрузку медиа.
• Положиться на Cloudflare, оставив сервер доступным напрямую по IP.
• Не сделать копию базы и файлов, или хранить её только на том же сервере.
• Поставить «плагин-заплатку» или сниппет с форума вместо обновления PHP.
• Менять пароли живых учёток самостоятельно вместо передачи владельцу списка на ротацию.
• Забыть про второстепенные сайты, поддомены и тестовые копии на том же сервере.

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