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

21 октября 2026 года команда PHP выпустила внеплановые обновления, а европейская группа реагирования на киберинциденты CERT-EU опубликовала экстренное предупреждение. Причина — две уязвимости с оценкой опасности 9,2 из 10, позволяющие злоумышленнику выполнить собственный код на вашем сервере. Без логина, без пароля, без единого действия со стороны ваших сотрудников.

PHP — это язык, на котором написано большинство сайтов в интернете: WordPress, Joomla, OpenCart, Bitrix, Laravel, а ещё сотни самописных скриптов, которыми сайт связывают с CRM, почтой или учётной системой. Если ваш сайт не на PHP — эту статью можно закрыть. Если вы не знаете, на чём он, — это уже повод спросить того, кто им занимается.

Что именно нашли

Уязвимостей две, обе оценены в 9,2 балла и обе ведут к одному результату — выполнению чужого кода на сервере без авторизации.

CVE-2026-109618 — срыв при нехватке памяти

В PHP есть настройка memory_limit: запрос, съевший слишком много памяти, обрывается принудительно. Проблема в том, как именно он обрывается. PHP может прерваться в момент, когда внутренние данные запроса заполнены лишь наполовину — например, пока разбирается файл, присланный через форму загрузки. Уборка после такого запроса принимает недоделанные данные за настоящие и пытается освободить память, которой никогда не было. А в той памяти может лежать то, что атакующий положил туда предыдущими запросами.

CVE-2026-109619 — остатки предыдущего запроса

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

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

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

Какие версии под угрозой

Всё, что ниже этих версий, — уязвимо:

Ветка PHP	Безопасная версия
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 и старше	поддержки нет

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

Почему «у нас маленький сайт» здесь не работает

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

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

Что делать — пошагово

1. Узнайте свою версию. В панели хостинга это раздел «Версия PHP» или «PHP Selector»; на собственном сервере — команда php -v. Важно проверить версию, которой работает именно сайт, а не ту, что стоит в командной строке: они часто разные.
2. Обновитесь в пределах своей ветки. Переход с 8.2.29 на 8.2.35 — это исправление внутри одной ветки: совместимость сохраняется, сайт от этого не ломается. Не путайте с переходом с 8.2 на 8.4 — вот он уже требует проверки.
3. Если у вас 8.1 или старше — поддержки этих ветвей нет. Из-за серьёзности ситуации команда безопасности PHP выпустила минимальные исправления и для 7.4, 8.0 и 8.1, а часть хостеров держит собственные сборки. Но правильное решение — переезд на поддерживаемую ветку, и лучше планировать его сейчас, а не в следующий раз.
4. Перезапустите обработчики. Без перезапуска php-fpm или Apache рабочие процессы дальше работают на старом коде, и обновление фактически не действует.
5. Проверьте результат. Проще всего — временная страница с phpinfo(), которую сразу после проверки нужно удалить, или же раздел «Версия PHP» в панели после перезагрузки.

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

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

Бывает, что сайт старый, а обновление требует подготовки. Тогда есть временные меры, сужающие окно для атаки:

• запретить переполнение памяти как точку входа: memory_limit=-1, заданный так, чтобы приложение не могло это переопределить, и проверка, что ни один пул или каталог не возвращает лимит назад;
• уменьшить post_max_size — 8M для сайтов без загрузки файлов, 32M если загрузки нужны, а upload_max_filesize держать ниже;
• выключить session.upload_progress.enabled и перезапустить все рабочие процессы;
• на PHP 8.5 дополнительно выключить fatal_error_backtraces;
• ограничить размер и сложность запросов на уровне веб-сервера или прокси.

Ни одна из этих мер не делает установку безопасной. Они лишь перекрывают известные пути — полностью проблему закрывает только обновление.

Если и это невозможно, CERT-EU советует простое и непопулярное решение: убрать уязвимый сервис из публичного интернета, пока исправление не будет установлено и проверено.

Откуда эти данные

• CERT-EU, Security Advisory 2026-018 «Critical Vulnerabilities in PHP»
• Объявление о выпуске обновлений на php.net
• Техническое описание CVE-2026-109618 и CVE-2026-109619

---

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