21 октября команда PHP выпустила PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 и раскрыла обе критические уязвимости, о которых предупреждала накануне. Утром я писал о самом предупреждении и о том, как подготовиться. Теперь есть номера CVE, версии и подробности.
Касается это почти всех, у кого PHP отвечает на веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Злоумышленнику не нужен логин: в худшем случае он запускает свой код на сервере с правами пользователя, под которым работает PHP. Сильнее всего рискуют сайты на mod_php: там атака срабатывает ещё до того, как начнёт выполняться код самого сайта. Патч есть, и, по словам команды PHP, полной защиты кроме обновления нет.
CVE-2026-109618: сбой при нехватке памяти
Когда запросу не хватает памяти, PHP аварийно выходит из текущего места через longjmp(). Иногда это случается в момент, когда внутренние данные запроса заполнены только наполовину. Потом при завершении запроса PHP работает с ними как с нормальными, и это можно довести до выполнения кода. Подробности в бюллетене GHSA-w8hw-w9fx-j79w.
Довести PHP до нехватки памяти можно запросом multipart/form-data, оставаясь в рамках лимитов. Например, без нормального Content-Length, с огромным числом заголовков внутри одной части или с кучей пустых полей для файлов с вложенными именами: такие поля не считаются в max_file_uploads, но память едят. Рабочий эксплойт показан против mod_php с настройками по умолчанию. Для FPM разработчики по исходникам считают дыру применимой, хотя готового эксплойта под него нет.
CVE-2026-109619: память прошлого запроса
Воркер PHP хранит глобальное состояние: ошибки, сессии, данные расширений. Если запрос оборвался на фатальной ошибке, нехватке памяти или по таймауту, часть этого состояния может остаться ссылкой на уже освобождённую память. Следующий запрос в том же воркере успевает прочитать её до обычной инициализации. Это use-after-free, утечка памяти и в итоге выполнение кода. Описание в бюллетене GHSA-6wmf-4rv5-p3rp.
Подтверждены два пути. Первый идёт через отслеживание прогресса загрузки (session.upload_progress), которое включено по умолчанию и не требует session_start() в коде сайта. Этот вариант доведён до выполнения кода и на mod_php, и на FPM с обычным динамическим пулом, хотя для FPM нужна подходящая операция в самом приложении. Второй путь: предупреждение о неверной или устаревшей настройке INI, применённой до старта запроса (.htaccess и php_value в Apache, PHP_VALUE от nginx в FPM). На PHP 8.5 к этому добавляется fatal_error_backtraces, на нём построен подтверждённый эксплойт против mod_php. Отключение display_errors, error_reporting и @ здесь не спасают.
У обеих дыр оценка 9.2 по CVSS 4.0. Сложность атаки помечена как высокая: эксплойту нужно угадать раскладку памяти конкретной сборки. Как пишет OpenNet, прототипы эксплойтов уже лежат в открытом доступе и перебирают заранее посчитанные смещения для пакетов разных дистрибутивов, а проблемы тянутся с PHP 5.4. Для файловой загрузки на сайте форма не нужна: хватает того, что PHP сам разбирает multipart/form-data.
Какие версии ставить и что с 7.4, 8.0 и 8.1
- ветка 8.5: 8.5.12;
- ветка 8.4: 8.4.27;
- ветка 8.3: 8.3.36;
- ветка 8.2: 8.2.35. Её поддержка заканчивается 31 декабря 2026 года, переезд пора планировать.
Ветки 8.1 и старше проект PHP больше не обновляет. Но из-за тяжести дыр команда безопасности PHP сама выложила минимальные патчи к исходникам для 7.4, 8.0 и 8.1. Они для тех, кто собирает PHP сам и не имеет поставщика с продлённой поддержкой. Остальным со старыми ветками команда советует спросить свой дистрибутив или LTS-поставщика о бэкпортах, а лучше перейти на поддерживаемую версию.
Дистрибутивы получили патчи заранее, так что пакеты должны появиться в обычных репозиториях. Отдельно команда PHP предупреждает пользователей rpms.remirepo.net: сегодня обновлений там не будет, и лучше перейти на пакеты дистрибутива или собрать PHP из исходников.
Как проверить и обновить PHP
Сначала версия. php -v показывает консольный PHP, а сайт может работать на другой ветке через FPM, поэтому смотрим и юниты.
php -v systemctl list-units 'php*-fpm.service' --no-pager
На Ubuntu и Debian обновляют пакеты своей ветки и перечитывают пул (номер ветки подставьте свой):
sudo apt update sudo apt install --only-upgrade 'php8.3*' sudo systemctl reload php8.3-fpm
На AlmaLinux, Rocky и других системах с dnf:
sudo dnf upgrade 'php*' sudo systemctl reload php-fpm
Номер версии в пакете дистрибутива может не совпадать с 8.x.y с php.net: Debian и RHEL часто переносят патч в старую версию и меняют только ревизию пакета. Тогда ориентир это бюллетень безопасности дистрибутива с CVE-2026-109618 и CVE-2026-109619. На mod_php после обновления нужен reload Apache. Если сайт в панели хостинга, проверьте в ней версию PHP и после обновления выберите ту же ветку заново, если панель её не подхватила.
Если обновиться прямо сейчас нельзя
Команда PHP предлагает меры, которые сужают атаку, но, как она сама подчёркивает, безопасным сервер не делают:
session.upload_progress.enabled=0в php.ini или в пуле FPM, затем перезапуск всех воркеров. Черезini_set()и.user.iniне работает;- на PHP 8.5 ещё
fatal_error_backtraces=0; memory_limit=-1черезphp_admin_value, чтобы сайт не мог вернуть лимит, и ограничение памяти на уровне контейнера или cgroup.RLIMIT_ASиRLIMIT_DATAдля этого не годятся, они как раз вызывают опасный сбой;- небольшой
post_max_size: 8M без загрузки файлов, 32M с ней, плюс лимиты размера запроса на nginx или прокси; - убрать устаревшие и неверные настройки, которые сыплют предупреждениями при старте запроса.
OpenNet приводит и самый грубый вариант: закрыть на nginx все запросы с типом multipart. Загрузка файлов через формы после этого перестанет работать, включая медиатеку WordPress.
if ($http_content_type ~* "multipart") {
return 403;
}
Итого: две дыры с оценкой 9.2 дают выполнить код на сервере без входа, эксплойты уже есть, сильнее всего рискует mod_php, но и FPM не в стороне. Ставьте 8.5.12, 8.4.27, 8.3.36 или 8.2.35 либо пакет дистрибутива с этими CVE и перечитывайте пул. На 8.1 и старше нужен бэкпорт или переезд.
