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

> 21 октября PHP закрыл две критические уязвимости удалённого выполнения кода. Какие версии безопасны и как обновить PHP на хостинге, VPS и в Docker.

Адрес: https://egerpro.ru/blog/kriticheskaya-uyazvimost-php-kak-obnovit/
Обновлено: 2026-10-22

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](https://egerpro.ru/uslugi/razrabotka-na-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 в «Здоровье сайта» и работу сайта: формы, оплату, [личный кабинет](https://egerpro.ru/uslugi/veb-servisy/).
- Обновить ядро WordPress, тему и плагины — это отдельная задача, но удобно сделать её за один заход.
- Просмотреть журналы веб-сервера за последние дни: необычные запросы, ошибки нехватки памяти, новые PHP-файлы в папке загрузок.
- При малейших признаках взлома — сменить пароли администраторов и доступы к базе данных.

## Чем поможем

Мы сопровождаем сайты на WordPress и собственных серверах: проверим версию PHP и источник пакетов, обновим без простоя, перезапустим службы и убедимся, что сайт работает. Подробнее — на странице [поддержки сайтов](https://egerpro.ru/uslugi/podderzhka-sajtov/), или [напишите нам](https://egerpro.ru/kontakty/): разберёмся с вашим сервером.

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

**Нужно ли обновлять WordPress, чтобы закрыть уязвимость?**

Нет. Уязвимость в PHP, а не в WordPress: обновление ядра и плагинов полезно, но эту проблему решает только обновление PHP на сервере.

**У меня Ubuntu и версия 8.3.6 — сайт уязвим?**

Номер ничего не говорит: Ubuntu переносит исправления в пакет 8.3.6. Проверьте журнал изменений пакета командой apt changelog php8.3-fpm или бюллетень безопасности Ubuntu. Если там есть CVE-2026-109618 и CVE-2026-109619, исправление установлено.

**Сайт работает на PHP 7.4 — что делать?**

Официальных выпусков для PHP 7.4, 8.0 и 8.1 нет. Временно помогут меры из статьи и заплатки дистрибутива, если он их выпускает, но сайт нужно переводить на PHP 8.3 или 8.4. Для старого кода это обычно доработка темы и плагинов.

**Достаточно ли временных мер?**

Нет. Команда PHP прямо пишет, что они перекрывают отдельные пути атаки, но не делают установку безопасной. Полное решение — обновление.

**Как понять, что сайт уже взломали?**

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

*Источники: [официальное объявление PHP от 21.10.2026](https://www.php.net/archive/2026.php#2026-10-21-5), бюллетени [GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) и [GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp). Статья актуальна на 22 октября 2026 года.*