В админке WordPress есть кнопка обновления. Но проблему PHP2Shell она не решит. Уязвимости нашли в самом PHP - языке, на котором работает WordPress, - а не в теме или плагине. Если у вас сайт небольшого бизнеса, сегодня важнее не искать волшебную настройку безопасности, а выяснить у хостинга две вещи: поставили ли патч и перезапустили ли после этого PHP.
Обновление, 22 окт: Wordfence и Patchstack поделились новыми деталями о реальном риске. В нашем продолжении про это и про то, что мы нашли на сайтах клиентов на обслуживании.
Разберемся, что уже известно, где пока нет ясности и какой вопрос отправить хостеру.
Что произошло с PHP2Shell?
PHP2Shell - название двух критических уязвимостей: CVE-2026-109618 и CVE-2026-109619. Первая связана с повреждением памяти, когда PHP упирается в ее лимит. Во второй между запросами сохраняется состояние, которое должно было сброситься. У обеих оценка CVSS - 9,2. Обе могут дать атакующему возможность запустить код на сервере без входа в аккаунт. Этот код работает от имени пользователя PHP на веб-сервере.
Уязвимости нашли исследователи Calif, Wiz и OpenAI. 20 октября команда PHP предупредила о скором выпуске исправлений. Патчи вышли 21 октября 2026 года в 13:30 UTC - в 16:30 по времени Таллинна. Исправленные версии: PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Более ранние выпуски в этих ветках уязвимы.
PHP 8.1 и старше уже сняты с поддержки: проект PHP не выпустит для них обычное обновление. Правда, некоторые дистрибутивы Linux и поставщики долгосрочной поддержки могут перенести исправления в старые пакеты. Команда PHP также опубликовала минимальные исправления исходного кода для 7.4, 8.0 и 8.1 - для тех, кто собирает PHP сам. Владельцу обычного сайта копаться в исходниках не нужно. Лучше перейти с 8.1 и более старых версий либо попросить хостинг подтвердить, что его пакет получил исправление.
По данным CERT-EU, в сети уже появились примеры эксплуатации. Технический директор Cloudflare сообщил о первых атаках и правилах файрвола, которые компания включила в ответ. Но эти правила он назвал временной мерой. Сколько сайтов пострадало, пока никто не знает. Точные цифры жертв сейчас звучали бы подозрительно.
Почему обновление WordPress не поможет
Wiz показала атаку до авторизации на сайтах с актуальными WordPress, Drupal и Joomla. Важно: эти движки были площадками для проверки, а не причиной проблемы. Уязвимость находится ниже - в PHP. Она затрагивает серверные конфигурации с PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed.
Самым рискованным вариантом команда PHP считает mod_php. В показанной атаке хватает одного запроса без авторизации: проблема срабатывает еще до запуска кода сайта. Плагин безопасности WordPress даже не успеет посмотреть на запрос. Обновление плагина или движка, правка wp-config.php - ничего из этого не чинит PHP. Его должен обновить тот, кто управляет сервером, а затем перезапустить.
Проверьте сайт сегодня
Для первого шага терминал не нужен. Откройте админку WordPress и пройдите по списку:
- Найдите
Tools > Site Health > Info > Serverв wp-admin. Посмотрите значениеPHP versionи запишите его. - Если там 8.1, 8.0, 7.4 или еще более старая версия, запросите переход на поддерживаемую ветку. После перехода проверьте формы, оформление заказа и запись на услуги. Есть тестовая копия сайта - сперва попробуйте на ней.
- Если стоит версия из веток 8.2, 8.3, 8.4 или 8.5, но ниже исправленного выпуска, спросите хостинг про патч. По одной цифре в админке окончательный вывод делать рано.
Вот почему цифра - лишь подсказка. Хостер может поставить пакет PHP с перенесенным исправлением, а номер версии, который видит WordPress, не изменится. Бывает и наоборот: вы проверили версию, но понятия не имеете, перезапустили ли PHP после установки пакета. Админка этого не покажет.
PHP2Shell checker: как проверить, установил ли хостинг исправление
Проверка через PHP2Shell checker - неплохой первый шаг для сайта на WordPress. Бесплатные онлайн-сервисы отправляют обычный запрос к главной странице, смотрят, какую информацию раскрывает сервер, например заголовок X-Powered-By, и сравнивают найденную версию PHP с первыми версиями, где есть исправление: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Эксплойт они не запускают. Если сервер скрывает версию, сервис не сможет сказать, установлен ли патч. И даже хороший результат проверки ничего не доказывает окончательно.
- Проверяйте только свой сайт. В WordPress откройте
Tools > Site Health > Info > Serverи запишите версию PHP, которая обрабатывает запросы к сайту. - Не полагайтесь на
php -v. В терминале может работать другая версия PHP, не та, которую использует Apache или PHP-FPM. - Спросите у хостинга, какой пакет PHP обслуживает ваш сайт. Если рядом установлено несколько версий, исправление нужно для каждой, которую может использовать сайт. Сам сайт при этом должен работать на версии с патчем.
- Попросите показать историю изменений пакета, где указаны и
CVE-2026-109618, иCVE-2026-109619. Человек с доступом к серверу может выполнитьrpm -q php-cli --changelogв системе на базе RPM. Разработчики дистрибутива иногда добавляют исправление, не меняя старый номер версии. Но и более высокий номер сам по себе ничего не доказывает. - Уточните, когда перезапускали процессы PHP-FPM и Apache. После обновления пакета в памяти еще может работать старый код.
Нормальный ответ хостинга содержит версию или название исправленного пакета, записи об обоих CVE, время перезапуска и подтверждение, что ваш сайт работает на PHP с патчем. Для проверки PHP2Shell WordPress я бы не запускал эксплойт на работающем магазине. Большая нагрузка от такого запроса может обрушить процесс и прервать запросы покупателей.
Что написать хостингу
Создайте тикет сегодня. На общем хостинге сервер обслуживает провайдер - самому накатывать патч вам некуда. Можно отправить такой текст, подставив название своего сайта:
«Подтвердите, пожалуйста, что PHP, обслуживающий мой сайт на WordPress, защищен от CVE-2026-109618 и CVE-2026-109619. Какая исправленная версия PHP или какой пакет с перенесенным патчем установлен? Когда его поставили и перезапустили ли после этого PHP? Если патча пока нет, когда он появится?»
В нормальном ответе назовут версию или пакет и подтвердят перезапуск. Фраза «мы следим за безопасностью» ответа не заменяет. Дистрибутивы Linux получили патчи заранее, так что многие хостеры могут действовать быстро. Если ваш не называет ни установленный пакет, ни дату исправления, я бы задумался о переезде. На нашем хостинге WordPress обновлять PHP для клиентов - наша работа. Гадать, кто за это отвечает, вам не придется.
Если патча пока нет
CERT-EU и британский NCSC советуют ставить исправление сразу. Если это невозможно, они предлагают рассмотреть отключение системы до установки патча. Для магазина, который принимает заказы, решение тяжелое. Но «подождем, пока хостер разберется» - тоже не план защиты. Спросите, что провайдер может сделать прямо сейчас и когда будет полноценное исправление.
Команда PHP перечислила временные меры на уровне сервера: выставить memory_limit=-1, чтобы приложения не могли переопределить настройку, держать post_max_size низким (8M без загрузки файлов или 32M с загрузкой), задать session.upload_progress.enabled=0, перезапустить каждый рабочий процесс и на PHP 8.5 установить fatal_error_backtraces=0. Меры снижают риск, но не делают сервер без патча безопасным. Через .user.ini или ini_set() надежно применить их тоже нельзя. Не тратьте полдня на поиски плагина, который якобы все исправит.
После патча присматривайте за сайтом
Патч закрывает дыру. Но если атакующий успел оставить бэкдор раньше, обновление его не удалит. NCSC советует проверять признаки взлома, если сайт какое-то время работал без исправления. В ближайшие недели обращайте внимание на такое:
- Незнакомые администраторы в WordPress или странные PHP-файлы в
wp-content/uploads. - Изменения в
.htaccess, неожиданные перенаправления, спамные страницы в выдаче Google. - Письма от хостинга с предупреждением «Malware detected». Не отмахивайтесь от них, но проверяйте сообщение через личный кабинет хостинга, а не по ссылке из письма.
Сохраните бэкапы, сделанные до 21 октября, - не затирайте их свежими копиями. Запустите сканирование на малварь, но помните, что сканер malware может пропустить. Результат «чисто» сам по себе ничего не гарантирует.
Нашли что-то странное? Сначала сохраните копию сайта, потом меняйте файлы. Если непонятно, с чего начать, вот порядок действий после взлома WordPress. А если разбираться некогда, можно передать нам очистку взломанного сайта. Для магазина с заказами это зачастую разумнее, чем наугад удалять подозрительные файлы.
Кто ставит исправление?
На общем хостинге вы можете проверить версию, отправить запрос и следить за ответом. Серверный патч ставит провайдер. Если вы сами управляете VPS, обновите пакеты PHP и перезапустите PHP; если сервер администрирует другой человек, перешлите ему вопросы выше. Не ждите уведомления в админке WordPress. Откройте тикет сегодня и попросите назвать пакет и время перезапуска - это займет пару минут.