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

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

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

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

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

Уязвимостей две, обе оценены в 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

---

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

Автор материала — SmartGT. Первоисточник: «Критические уязвимости PHP: обновление нельзя откладывать».