Коротко: это не «обновите, когда удобно». Обе 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 выше.

Повод ускориться неприятный: информация об уязвимостях утекла до официального disclosure. Сначала пост на Hacker News (потом удалили), затем подтверждение от исследователей watchTowr. PHP прямо написали: имеют право выпустить патч раньше, если детали станут публичными или появится эксплуатация в дикой природе.

Официальный анонс: Upcoming Critical PHP Security Release. Разбор ситуации: BleepingComputer.

Что уже известно

Пока официально PHP подтвердили только рейтинг и дату релиза. CVE-номера и «это RCE» в их коротком анонсе не расписаны — детали обещают вместе с патчами.

Из параллельных источников (watchTowr → BleepingComputer, CERT-EU, ACSC):

• идентификаторы: CVE-2026-109618 и CVE-2026-109619;
• тип: remote code execution (удалённое выполнение кода);
• watchTowr оценивает как CVSS 10, PHP официально ставит каждой 9.2 по CVSS v4.0 — расхождение в шкалах, не в том, что «не страшно»;
• по оценке исследователей, затронуты ветки PHP 5 / 6 / 7 / 8 (то есть фактически «почти всё, что ещё крутится в проде»);
• на момент предупреждений активной эксплуатации в wild не видели — но окно после утечки и до патча как раз самое опасное.

Ожидаемые fixed-релизы (по сообщениям security-комьюнити, не финальный список от PHP до момента публикации патчей): 8.5.12, 8.4.27, 8.3.36, 8.2.35. EOL-ветки вроде PHP 7.4 / 8.0 / 8.1 патча могут и не получить — рассчитывать на «дистр когда-нибудь подтянет» для мёртвой ветки наивно.

Почему это важно именно вам

PHP — это не «какой-то фреймворк». На нём сидят WordPress, Битрикс, Laravel, Magento, куча самописных ЛК и API. Если дыра в интерпретаторе и она RCE — компрометируется не «один плагин», а процесс php-fpm / apache-модуль. Дальше классика: шелл, бэкдор в wp-content, кража wp-config / .env, рассылка, ботнет.

После историй с wp2shell и массовыми взломами Битрикса сценарий знакомый: disclosure → через сутки сканеры по интернету → через неделю «у нас странный админ и левый плагин». Здесь ещё и leak до релиза — значит, кто умеет, уже мог готовить эксплойт, пока вы читаете новость.

Что сделать прямо сейчас

1. Инвентаризация. Пройдитесь по серверам и узнайте, где какой PHP:

php -v
# или на сайте
<?php echo PHP_VERSION;

Отдельно — контейнеры, shared-хостинг клиентов, «забытые» лендинги на старом 7.4. Список версий и хостов лучше иметь до того, как пакеты появятся в репозитории.

2. Подготовить обновление. На Debian/Ubuntu заранее проверить, откуда тянете PHP (ondrej/php, вендорский репозиторий, remi на RHEL). На VPS с ручной сборкой — план: скачать релиз → подменить → reload php-fpm. На shared — тикет хостеру: «когда выкатите security-релиз PHP от 21.10».

3. Как только пакеты вышли — ставить без отлагательств. Для поддерживаемых веток цель простая: оказаться на fixed-версии своей линии (или новее). После обновления:

systemctl reload php*-fpm
# или
systemctl restart php8.3-fpm apache2

И проверить, что сайт реально отвечает уже новым бинарником, а не старым php-fpm из другого pool.

4. EOL — отдельно. Если сайт на PHP 7.x или 8.0/8.1 и вендор патч не выпустит — это не «подождём», а миграция на поддерживаемую ветку. Временные костыли (WAF, закрыть наружу) — только мост, не лечение.

5. Пока патча нет / нельзя сразу обновить. CERT-EU прямо советует: где нельзя пропатчить мгновенно — по возможности изолировать интернет-facing приложения. На практике: усилить WAF/Cloudflare, убрать лишний PHP с публичных vhost’ов, закрыть ненужные entrypoint’ы, не торчать phpMyAdmin в мир. Это не замена патчу.

6. После патча — быстрый чек на компрометацию. Особенно если сервер торчал в интернет всё окно утечки. Смотрите новые PHP в uploads / странных каталогах, левых пользователей в CMS, неожиданные cron, правки .htaccess / nginx, неизвестные процессы от www-data. Патч закрывает вход — бэкдор, уже залитый до обновления, сам не исчезнет (мы это уже проходили на Битриксе и WordPress).

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

• Не гонять по себе чужие «PoC с GitHub», пока нет официального advisory — половина будет фейком или сама шеллом.
• Не путать CVSS 9.2 от PHP и «CVSS 10» из твитов: это разные формулировки одной критичности, а не две разные дыры.
• Не ждать, что «WordPress сам обновит PHP» — CMS ядро обновляет, интерпретатор на сервере — ваша зона.

Что дальше

После 14:00 UTC 21 октября на php.net должны появиться changelog’и и список affected/fixed. Как только будут точные версии и описание вектора — имеет смысл свериться ещё раз: не все сборки дистрибутивов выходят в ту же минуту, что upstream.

Если коротко: сегодня это не «интересная CVE для чтения на выходных», а окно, в котором нужно знать свои версии PHP и быть готовым нажать обновление в первые часы после релиза. WordPress, Битрикс, самопис — неважно: дыра в PHP бьёт по всему стеку.

Нужна помощь — пробежать серверы, обновить PHP на VPS, проверить сайты после патча — пишите через контакты.