Срочное обновление PHP для сайта:
закрываем критические уязвимости

Что произошло

21 октября 2026 года проект PHP выпустил исправления для двух критических уязвимостей: CVE-2026-109618 и CVE-2026-109619. Обе связаны с работой PHP с памятью и оценены в 9,2 балла из 10 по шкале CVSS v4.0. По описанию проекта, они могут позволить выполнить код на сервере удалённо и без аутентификации.

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

Исправления вошли в версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Ветки PHP 8.1 и старше обновлений от проекта больше не получают.

Чем это опасно для сайта

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

Что делать

1. Узнать версию PHP на каждом сайте и поддомене. Тестовые и забытые копии тоже в списке.
2. Обновить PHP до исправленной версии: 8.2.35, 8.3.36, 8.4.27 или 8.5.12. На виртуальном хостинге это обычно переключатель версии в панели, на VPS обновление пакетов из репозитория дистрибутива с последующим перезапуском процессов PHP.
3. Проверить сайт после переключения: формы, загрузку файлов, оплату, интеграции. Старый код и модули на новой версии могут перестать работать.
4. Если обновиться сразу нельзя, применить временные меры. Проект PHP называет такие меры частичными: они снижают риск, но не делают установку безопасной. Это настройка session.upload_progress.enabled = 0, ограничение размера POST-запросов, где не нужна загрузка файлов, и перезапуск процессов. Применять их нужно в конфигурации сервера до разбора запроса, ini_set() и .user.ini для этого не подходят.

Хостинги тоже вводят временные ограничения. Например, Beget ограничил механизм upload_progress и временно закрыл доступ к phpMyAdmin и Adminer для облачных баз, из-за чего у клиентов возможны перебои с формами и загрузкой файлов. На такие ограничения закладываться не стоит: они не заменяют обновление.

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

Достаточно ли просто переключить версию PHP в панели хостинга?

Часто да, но переключать боевой сайт без проверки опасно: старые плагины и самописный код могут перестать работать на PHP 8.2 и новее. Мы сначала проверяем сайт на тестовой копии, а потом переключаем боевой.

У нас сайт на PHP 7 или 5.6. Что делать?

Для версий ниже 8.2 готовых исправлений нет, а минимальные патчи для 7.4, 8.0 и 8.1 доступны только для сборки из исходников. Полноценный путь один: переход на PHP 8.2 и новее. Для старых движков для этого придётся обновить саму CMS и модули. Объём работ оцениваем после аудита.

Вы работаете с Битрикс, MODX, WordPress?

Да, с любыми сайтами на PHP. Для каждой CMS сначала проверяем, поддерживает ли её версия нужный PHP, и только потом переключаем.

Сколько это стоит?

Зависит от числа сайтов, текущей версии PHP и состояния движка. Стоимость называем после аудита, до начала работ.

Нужно ли менять пароли после обновления?

Если сайт работал на уязвимой версии, разумно проверить журналы и файлы на подозрительные изменения и сменить пароли доступа к хостингу, базе и админке. Мы делаем это отдельным шагом по вашему желанию.