Коротко: это не «обновите, когда удобно». Обе CVE — unauthenticated RCE. На Apache mod_php эксплойт показали до запуска кода вашего сайта. Полных временных костылей нет — только обновление. Ниже — что именно починили, кого бьёт и как быстро проверить, что вы уже на патче.

Какие версии ставить

PHP 8.1 и старше upstream больше не патчит. Для 7.4 / 8.0 / 8.1 выложили минимальные source-backport’ы — если собираете сами или ждёте пакет от LTS-вендора. На Remi PHP-команда прямо написала: сегодня обновлений в rpms.remirepo.net не будет, берите дистрибутивные пакеты или собирайте из исходников.

Проверка после обновления:

php -v
# и обязательно через веб — тот же php-fpm/mod_php, что обслуживает сайт
<?php echo PHP_VERSION;

CLI может уже быть новым, а пул FPM — старым. После пакета — reload/restart воркеров.

CVE-2026-109618 — RCE через OOM

Advisory: GHSA-w8hw-w9fx-j79w. CVSS v4.0 — 9.2.

Суть простым языком: при нехватке памяти PHP раньше уходил через longjmp(), обрывая обработку запроса. Иногда это случалось, когда внутренняя структура запроса ещё не до конца инициализирована. Cleanup потом смотрел на это «полусобранное» состояние как на нормальное — отсюда порча памяти и путь к RCE.

OOM можно спровоцировать не только «тяжёлым скриптом»: multipart без нормального Content-Length, куча заголовков внутри part’ов, пустые file-поля, глубокая вложенность имён полей — всё это раздувает память сильнее, чем кажется по post_max_size.

Самое неприятное: на mod_php атака возможна до любого кода приложения. FPM по анализу тоже в зоне риска (полный публичный эксплойт под FPM на момент advisory не демонстрировали, но «мы на nginx+php-fpm — нам норм» — плохой вывод).

В патче: отказ от опасного longjmp() на OOM, soft/hard OOM через нормальные точки остановки, shutdown больше не видит битое состояние.

CVE-2026-109619 — RCE через «протухшее» состояние

Advisory: GHSA-6wmf-4rv5-p3rp. Тоже 9.2.

Здесь другая история: внутреннее состояние, привязанное к запросу, может пережить освобождение памяти. Следующий запрос на том же воркере успевает опереться на stale state, пока нормальная инициализация его не сбросила. Классический use-after-free на уровне рантайма — снова без логина.

Обе дыры закрыты одним пакетом релизов. Если обновились — закрыли обе.

Кто в зоне риска

По словам PHP Security Team — все установки PHP, которые отдают веб-запросы:

• PHP-FPM
• Apache mod_php (риск считают наивысшим)
• php-cgi
• FrankenPHP
• LiteSpeed / LSAPI

Не только «публичный WordPress». Ещё админки, панели, контейнеры, appliances, где PHP вшит и про него часто забывают. WordPress, Битрикс, Laravel, самопис — всё на одном интерпретаторе.

Как обновить на практике

Debian / Ubuntu (ondrej или вендорский репозиторий):

sudo apt update
sudo apt install --only-upgrade php8.3-fpm php8.3-cli   # подставьте свою ветку
sudo systemctl restart php8.3-fpm
# если Apache+mod_php:
sudo systemctl restart apache2

RHEL / Alma / Rocky: пакеты от дистрибутива или AppStream; не ждите сегодня Remi.

Docker: пересобрать образ на php:8.x.y с fixed-тегом / digest, задеплоить заново. Один docker pull без recreate контейнера не спасёт старый процесс.

Shared-хостинг: тикет хостеру + проверка phpinfo() / версии в панели. «Мы обновим на выходных» для этой дыры — плохой ответ.

После рестарта убедитесь, что все пулы/vhost’ы реально на новой версии, а не только дефолтный.

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

PHP честно пишет: полного mitigation нет. Ниже — только снижение отдельных векторов, пока катите пакет.

Для CVE-2026-109618:

• memory_limit=-1 через php_admin_value в FPM/Apache так, чтобы приложение не вернуло лимит обратно;
• низкий post_max_size (например 8M без аплоадов, 32M если аплоады нужны), upload_max_filesize ниже него;
• лимиты на размер/число multipart/headers на nginx/прокси;
• не использовать RLIMIT_AS / RLIMIT_DATA как «защиту» — они как раз могут спровоцировать уязвимый путь.

Для CVE-2026-109619:

• session.upload_progress.enabled=0 и рестарт всех воркеров (не через ini_set / .user.ini);
• на PHP 8.5 — fatal_error_backtraces=0;
• убрать странные per-request deprecated settings, которые сыплют диагностикой до инициализации.

WAF в одиночку PHP не считает достаточной защитой. Временные меры — мост на часы/сутки, не замена патчу.

После патча — не забыть про компрометацию

Окно между утечкой (20 октября) и массовым обновлением уже открыто. Обновление закрывает вход — уже залитый шелл не удалит. Имеет смысл:

• логи на странные multipart/огромные POST, падения воркеров, всплески 5xx;
• новые .php в uploads / странных каталогах;
• левые пользователи в CMS, правки cron, mu-plugins, неожиданные процессы от www-data.

Тот же урок, что после wp2shell и массовых взломов Битрикса: сначала чистка, если уже задели, потом спокойная жизнь на патче.

Чеклист на сегодня

1. Узнать текущую ветку PHP на каждом сервере/контейнере.
2. Поставить fixed-релиз своей линии (или пакет вендора с бэкпортом).
3. Перезапустить php-fpm / Apache / контейнеры.
4. Проверить версию именно через HTTP, не только CLI.
5. Если сидите на 7.4/8.0/8.1 — ускорить миграцию или бэкпорт вендора.
6. Пробежать логи и файлы на следы компрометации.

Исходники и Windows-сборки — на downloads.php.net. Полный разбор — в advisory на архиве новостей и в двух GHSA выше.