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

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

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

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

Уязвимостей две, обе оценены в 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: обновление нельзя откладывать».