Критическая уязвимость PHP: как проверить сервер и обновиться

21 октября 2026 года разработчики PHP выпустили версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают две критические уязвимости, через которые злоумышленник может выполнить свой код на сервере без входа на сайт, — удалённое выполнение кода (Remote Code Execution, RCE). Обе получили 9,2 балла из 10 по шкале CVSS. Ошибка находится в самом интерпретаторе, поэтому под угрозой любой сайт на PHP: WordPress, «1С-Битрикс», Laravel или самописный.

Ниже — что именно исправлено, как за пять минут проверить свой сервер и как обновиться на виртуальном хостинге, на своём сервере с ISPmanager, на виртуальном сервере (VPS) с Ubuntu или Debian и в контейнерах Docker.

Что случилось

Исследователи дали уязвимостям общее название PHP2Shell. Обе связаны с тем, как PHP обращается со служебными данными запроса:

• CVE-2026-109618 — ошибка при нехватке памяти. Если PHP прерывается из-за нехватки памяти в момент, когда данные запроса подготовлены лишь частично, при очистке он может принять повреждённые данные за корректные.
• CVE-2026-109619 — «устаревшее» состояние. Внутренние данные одного запроса могут пережить освобождение памяти, и следующий запрос, который обрабатывает тот же процесс, воспользуется ими раньше, чем PHP их сбросит.

По данным команды PHP, для режима mod_php (PHP как модуль веб-сервера Apache) продемонстрирована атака, которая срабатывает одним запросом без авторизации ещё до того, как запускается код сайта. Поэтому обновление плагинов и защитные плагины WordPress здесь не помогают: уязвимость находится уровнем ниже.

Какие версии безопасны

Ветка PHP	Уязвимы	Исправлено в
8.5	до 8.5.11 включительно	8.5.12
8.4	до 8.4.26 включительно	8.4.27
8.3	до 8.3.35 включительно	8.3.36
8.2	до 8.2.34 включительно	8.2.35
8.1, 8.0, 7.4	все версии	официальных выпусков нет

PHP 8.1 и более старые ветки проект больше не поддерживает. Для тех, кто собирает PHP из исходного кода, команда PHP выложила минимальные исправления и для веток 7.4, 8.0 и 8.1, а часть дистрибутивов выпускает собственные заплатки. Но правильный путь — перейти на поддерживаемую версию.

Под угрозой все способы запуска PHP для веб-запросов: PHP-FPM (менеджер процессов PHP, самый распространённый вариант на хостингах), mod_php в Apache, php-cgi, FrankenPHP и LiteSpeed. Выше всего риск у mod_php.

Как проверить версию PHP

• В WordPress: «Инструменты» → «Здоровье сайта» → «Информация» → «Сервер», строка «Версия PHP». Это та версия, на которой работает сам сайт.
• В панели хостинга или ISPmanager: в настройках сайта, где выбирается версия PHP.
• По SSH (удалённый доступ к серверу): команда ниже. Она показывает версию консольного PHP — у сайта она может быть другой, поэтому сверяйтесь с данными WordPress.

php -v

Важная деталь: дистрибутивы Linux часто не меняют номер версии, а переносят исправление в старый пакет. Например, PHP 8.3 в Ubuntu 24.04 называется 8.3.6 при любых обновлениях. Поэтому на таких серверах смотрите не на номер, а на бюллетень безопасности дистрибутива и журнал изменений пакета — в нём должны упоминаться CVE-2026-109618 и CVE-2026-109619:

apt changelog php8.3-fpm | head -40

Как обновить PHP

Виртуальный хостинг

PHP обновляет хостинг-провайдер. Проверьте новости хостинга или спросите в поддержке, установлено ли исправление для CVE-2026-109618 и CVE-2026-109619. Если в панели можно выбрать версию PHP, выберите актуальную поддерживаемую ветку — 8.3 или 8.4, предварительно проверив совместимость сайта.

Свой сервер с ISPmanager

ISPmanager ставит версии PHP пакетами — из репозитория операционной системы или из собственного (альтернативные версии лежат в каталогах вида /opt/php83). Обновите системные пакеты и пакеты панели, затем перезапустите службы PHP и веб-сервер. Если исправленные пакеты для вашей версии ещё не вышли, следите за новостями ISPmanager и включите временные меры из раздела ниже.

VPS с Ubuntu или Debian

sudo apt update
sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm
# если PHP работает как модуль Apache:
sudo systemctl restart apache2

Замените 8.3 на свою ветку. Если PHP установлен из репозитория Ondřej Surý (ppa:ondrej/php или packages.sury.org), обновления придут оттуда с «настоящими» номерами — 8.3.36, 8.4.27 и так далее.

Контейнеры Docker

Официальные образы php и wordpress пересобираются с новой версией PHP. Скачайте свежий образ и пересоздайте контейнеры:

docker compose pull
docker compose up -d --build

Если образ закреплён на конкретной версии, например php:8.3.35-fpm, поменяйте её на 8.3.36. Версию внутри контейнера проверяет команда docker compose exec <сервис> php -v.

Обязательно перезапустите PHP

Пока работают старые процессы, в памяти остаётся старый код. После обновления перезапустите все процессы PHP-FPM и веб-сервер, а затем ещё раз проверьте версию в «Здоровье сайта»: там должна быть исправленная сборка.

Если обновиться прямо сейчас нельзя

Команда PHP перечисляет временные меры. Они перекрывают известные пути атаки, но не делают сервер безопасным — это мост до обновления, а не замена ему.

• CVE-2026-109618: memory_limit = -1, заданный так, чтобы сайт не мог его переопределить, — через php_admin_value в пуле PHP-FPM или в конфигурации Apache. Проверьте, что ни пул, ни каталог, ни сам сайт не возвращают конечный лимит.
• Небольшой post_max_size: 8M, если сайту не нужна загрузка файлов, и 32M — если нужна; upload_max_filesize — меньше post_max_size. Ограничьте размер запросов и на уровне веб-сервера или прокси.
• Ограничьте память контейнера или группы процессов (cgroup) так, чтобы при превышении завершался только один процесс. Ограничения RLIMIT_AS и RLIMIT_DATA для этого не подходят — они сами вызывают уязвимую ошибку.
• CVE-2026-109619: session.upload_progress.enabled = 0 в php.ini или в настройках пула и перезапуск всех процессов. Через ini_set() или .user.ini это не работает.
• На PHP 8.5 дополнительно fatal_error_backtraces = 0.
• Уберите устаревшие и неверные настройки, которые выдают предупреждения при каждом запросе, и исправьте фатальные ошибки и превышения времени выполнения, которых можно добиться извне. Скрыть ошибки через error_reporting или display_errors недостаточно.

Учтите: memory_limit = -1 снимает ограничение памяти для сайта. Без лимита на уровне контейнера или cgroup один тяжёлый запрос может занять всю память сервера.

Что сделать после обновления

• Проверить версию PHP в «Здоровье сайта» и работу сайта: формы, оплату, личный кабинет.
• Обновить ядро WordPress, тему и плагины — это отдельная задача, но удобно сделать её за один заход.
• Просмотреть журналы веб-сервера за последние дни: необычные запросы, ошибки нехватки памяти, новые PHP-файлы в папке загрузок.
• При малейших признаках взлома — сменить пароли администраторов и доступы к базе данных.

Чем поможем

Мы сопровождаем сайты на WordPress и собственных серверах: проверим версию PHP и источник пакетов, обновим без простоя, перезапустим службы и убедимся, что сайт работает. Подробнее — на странице поддержки сайтов, или напишите нам: разберёмся с вашим сервером.

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

Источники: официальное объявление PHP от 21.10.2026, бюллетени GHSA-w8hw-w9fx-j79w и GHSA-6wmf-4rv5-p3rp. Статья актуальна на 22 октября 2026 года.