Две дыры в PHP на 9,2 балла: что это значит для бизнеса и сколько стоит промедление

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

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

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

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