Как обновиться быстрее, чем хакерский ИИ допишет свой эксплойт

«CVE-2026-109618 и CVE-2026-109619? Похоже на номера разрешений на строительство», — заметил Самсон Ярдов, пробегая глазами рассылку от хостинга между звонком поставщику бетона и совещанием по смете. Два длинных номера, пара непонятных аббревиатур. Рутина, решил он, и отложил письмо в сторону.

Технический специалист, заглянув через плечо, вернул письмо на экран: «Это не разрешения. Это две критические уязвимости в самом PHP, оценка 9,2 из 10. По вашей шкале — не царапина на обоях, а трещина в несущей стене. И ключи от этой стены уже ищут все, кому не лень». Самсон перечитал письмо ещё раз, уже внимательно, и задал единственный вопрос, который имеет значение в таких случаях: «Когда обновляемся?» — «Сегодня». — «Тогда начинайте».

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

Две критические уязвимости сидят в самом PHP, а не в плагинах

Разработчики PHP опубликовали информацию об уязвимостях 21 октября 2026 года, обе получили оценку 9,2 по шкале CVSS v4.0 и исправлены в версиях 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Оценка выше 9 — это «критическая»: на языке безопасности «бросайте всё и обновляйтесь».

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

Масштаб впечатляет: по телеметрии Palo Alto Unit 42, в интернете обнаружено более 22,6 миллиона экземпляров, потенциально уязвимых к этим CVE. Среди них, вполне вероятно, и ваш сервер.

Есть и нюанс для любителей чёрной статистики. Исследователи высказывали предположение, что одна из уязвимостей может затрагивать и очень старые ветки PHP, вплоть до пятой, но это не подтверждено официальным заявлением разработчиков. Так что если у вас древний PHP, надеяться на «авось не заденет» не стоит.

Пытливые умы юных хакеров берут свежие уязвимости на вооружение

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

Поэтому правило одно: обновляться быстрее, чем хакерский ИИ допишет свой эксплойт. Не «на выходных», не «после праздников», а сегодня.

Какие версии PHP уже получили исправление

Обратите внимание на последнюю строку. Для PHP 8.1 и более старых версий разработчики исправления выпускать не будут: они сняты с поддержки. Владельцам таких сайтов обновление не «желательно», а единственный выход. Планировать переход стоит на актуальную ветку, предпочтительно PHP 8.4. О том, как перевести сайт на новую версию PHP без белого (читай синего 🙂 ) экрана и валидола, мы подробно писали в статье → Как обновить PHP без криков, валидола и вызова экзорциста.

Обновляем PHP до 8.3.36 из репозитория по шагам

Самый надёжный способ закрыть уязвимости — установить исправленную версию PHP из репозитория. Ниже инструкция для сервера на Ubuntu с Hestia CP, как в наших предыдущих материалах. Команды выполняются под root или через sudo.

Шаг 1. Сделайте резервную копию. Перед любыми работами с сервером сохраните актуальные копии файлов и баз данных. В Hestia это делается одной командой (замените ПОЛЬЗОВАТЕЛЬ на имя пользователя панели):

v-backup-user ПОЛЬЗОВАТЕЛЬ

Шаг 2. Выясните, какие версии PHP реально установлены. Не доверяйте вслепую команде php -v: она показывает версию для консоли, а сайт может обслуживаться совсем другой. Проверьте все установленные версии и ту, что выбрана для вашего сайта (как узнать её через phpinfo.php, описано в посте → Как проверить версию PHP через phpinfo):

dpkg -l | grep -E '^ii\s+php[0-9]+\.[0-9]+-(cli|fpm)'
/usr/sbin/php-fpm8.3 -v

Шаг 3. Обновите пакеты PHP. Обновляем только пакеты нужной ветки:

sudo apt update
sudo apt install --only-upgrade 'php8.3*'

Если на сервере установлено несколько веток PHP (например, 8.2 и 8.4 для разных сайтов), повторите команду для каждой, заменив номер версии. Если сайты работают в Docker, недостаточно просто перезапустить контейнеры: образы нужно пересобрать.

Шаг 4. Перезапустите службы. Это обязательный шаг: пока службы не перезапущены, в памяти продолжает работать старый уязвимый код, а обновлённые файлы лежат на диске без дела.

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2
sudo systemctl restart nginx

Шаг 5. Проверьте результат. Убедитесь, что версия обновилась, и откройте сайт: главная, пара внутренних страниц, админка, формы.

/usr/sbin/php-fpm8.3 -v

Если PHP на сервере ставился из репозитория Ondřej Surý (для Hestia это обычная история), в выводе увидите 8.3.36. Если же стоит пакет из стандартных репозиториев Ubuntu, номер версии может остаться прежним: дистрибутивы часто переносят исправления в старую версию, не меняя нумерацию. В таком случае сверьтесь с журналом изменений пакета и найдите в нём номера CVE:

apt changelog php8.3-fpm | head -n 40

И последнее: если сайт после обновления повёл себя странно, включайте отладку и смотрите лог. Как это сделать правильно, рассказывает статья → Как включить и настроить debug в WordPress.

Для тех, кто пользуется серверами на базе AlmaLinux и репозиторием Remi, есть отдельное предупреждение. В уведомлении хостинга от 21 октября сообщалось, что обновления в Remi на тот момент были временно недоступны, и советовали использовать стандартные пакеты дистрибутива или дождаться бэкпорт-патчей. С тех пор ситуация могла измениться, так что проверьте актуальное состояние репозитория, прежде чем что-то планировать.

Временные меры пригодятся, если обновиться прямо сейчас нельзя

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

Шаг 1. Отключите отслеживание прогресса загрузки файлов. Откройте конфигурацию PHP-FPM (для ветки 8.3 в Ubuntu это обычно /etc/php/8.3/fpm/php.ini) и пропишите:

session.upload_progress.enabled = 0

Важно: менять значение нужно именно в php.ini или в конфигурации пула PHP-FPM. Изменение через ini_set() или файл .user.ini необходимой защиты не даёт.

Шаг 2. Для PHP 8.5 добавьте ещё одну настройку:

fatal_error_backtraces = 0

Шаг 3. Ограничьте размер запросов. Если загрузка файлов на сайте не нужна, поставьте post_max_size = 8M. Если нужна (а на WordPress-сайте, где вы загружаете картинки, она нужна почти наверняка), поставьте 32M, а значение upload_max_filesize задайте меньшим. Например:

post_max_size = 32M
upload_max_filesize = 16M

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

Шаг 4. Перезапустите PHP-воркеры, чтобы изменения вступили в силу:

sudo systemctl restart php8.3-fpm

Шаг 5. Включите WAF (Web Application Firewall) для фильтрации подозрительных HTTP-запросов. Если у вас есть приложения, которым не обязательно быть доступными всему интернету, закройте их за WAF или ограничьте доступ через VPN.

Ещё раз для тех, кто любит читать только последний абзац: все перечисленные меры лишь снижают риск и не гарантируют полной защиты. Чтобы закрыть уязвимости, нужно установить исправленный PHP.

К вечеру технический специалист доложил Самсону: PHP на серверах компании «Строим крутые дома» обновлён, службы перезапущены, сайт и калькулятор стоимости работ работают штатно. Самсон кивнул так, как кивают люди, привыкшие принимать объекты без замечаний.

Выводы он записал в свой блокнот:

• Критическая оценка в уведомлении — это не повод «потом разберёмся», а повод разобраться сегодня
• Уязвимость в самом PHP не лечится ни плагинами, ни паролями посложнее, только обновлением
• Перед любыми работами на сервере — резервная копия, всегда
• Версию PHP проверяем там, где она реально обслуживает сайт, а не в консоли

Если у вас нет времени разбираться с репозиториями, службами и версиями PHP самостоятельно, направьте задачу в свободной форме в dev-team Форсаж. Проверим, какая версия PHP реально обслуживает ваш сайт, обновим её и убедимся, что сайт работает как прежде.