21 октября PHP выпустил внеплановые релизы 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают две уязвимости, которые по описанию проекта позволяют выполнить код на сервере без аутентификации: CVE-2026-109618 и CVE-2026-109619. У обеих CVSS 4.0 равен 9.2, severity critical.

Ниже: кого это касается, как проверить свою версию за минуту, как обновиться и что делать, если обновиться прямо сейчас нельзя.

Кого касается

По сводке на php.net, под риском все установки PHP, которые обслуживают веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Выше всего риск у mod_php: проект пишет, что для него показан эксплойт, где неаутентифицированный запрос срабатывает до выполнения кода приложения.

Уязвимы все версии ниже 8.2.35, 8.3.36, 8.4.27 и 8.5.12. PHP 8.1 и старше проект больше не обновляет. Для 7.4, 8.0 и 8.1 команда безопасности выложила минимальные бэкпорты исходников в ветках php-src (PHP-7.4-CVE-2026-109618-109619 и аналогичные для 8.0 и 8.1). Дистрибутивы и LTS-вендоры могут дать свои бэкпорты, это стоит уточнить у них.

Что именно исправлено

Если коротко, по описаниям из advisory:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): обработка нехватки памяти может прервать PHP, пока внутренние данные запроса инициализированы не до конца, и очистка запроса примет их за валидные.

• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): внутреннее состояние запроса может пережить освобождение своей памяти, и следующий запрос, который обработает тот же воркер, воспользуется устаревшим состоянием.

Для FPM картина менее ясна: анализ исходников считает его уязвимым, но полного эксплойта для FPM проект не показывал. Это не повод откладывать обновление.

В ChangeLog обе правки записаны одной строкой в разделе Core: «Avoid state corruption via bailout».

Проверка за минуту

Важно проверить именно ту сборку, что отвечает на веб-запросы. CLI и FPM в одном контейнере или на одном хосте могут оказаться разными версиями.

php -v
php-fpm -v                       # версия, которая реально обслуживает веб
docker exec <контейнер> php -v   # для контейнеров
php -r 'var_dump(version_compare(PHP_VERSION, "8.4.27", ">="));'   # подставьте свою ветку

Пороги: 8.5.12, 8.4.27, 8.3.36, 8.2.35. Всё, что меньше, нужно обновлять.

Как обновиться

Пакеты дистрибутива. Дистрибутивы и LTS-вендоры получили патчи заранее, поэтому первым делом посмотрите обновления у своего вендора. Отдельно php.net предупреждает: репозиторий rpms.remirepo.net сегодня обновлений не получит, тем, кто на нём, рекомендуют перейти на пакеты дистрибутива или собирать из исходников.

Официальные образы Docker. На 15:00 UTC 21 октября в php:* на Docker Hub были только релиз-кандидаты. Я проверил это сам в 15:20 UTC:

$ for t in 8.5-cli 8.4-cli 8.3-cli 8.2-cli; do
    docker run --rm --pull always php:$t php -r 'echo PHP_VERSION,"\n";'
  done
8.5.11
8.4.26
8.3.35
8.2.34

Все четыре версии ещё уязвимые. Исправление в репозитории docker-library/php уже смержено (коммит e3eaff8), так что образы появятся с обычной задержкой. Если ждать не хочется, образ можно собрать самим из Dockerfile этого репозитория, подставив исправленную версию и её SHA256 с php.net.

Наши готовые образы. Мы собрали такой набор: stufently/php-patched-images (MIT), образы лежат в ghcr.io/stufently/php-patched-images. Что внутри:

• PHP собирается из исходников по Dockerfile docker-library/php с коммита e3eaff8; тарбол проверяется по SHA256 с php.net, база — Debian 13 trixie-slim;

• ветки 8.5, 8.4, 8.3 и 8.2, варианты cli, fpm и apache, архитектуры amd64 и arm64;

• сборка раз в неделю, чтобы подтягивать обновления Debian; перед публикацией CI проверяет версию, список расширений и реальный запрос через FPM и Apache;

• теги 8.5-fpm, точные 8.5.12-fpm-web и датированные неизменяемые вида 8.5.12-fpm-web-YYYYMMDD;

• профили с расширениями: web (WordPress, OpenCart, Joomla, Drupal), app (Laravel, Symfony, воркеры, плюс composer), dev (с xdebug, не для прода).

Переход обычно сводится к замене одной строки и пересборке:

FROM ghcr.io/stufently/php-patched-images:8.5-fpm

Проверка:

docker run --rm ghcr.io/stufently/php-patched-images:8.5-cli php -v

После любого обновления перезапустите все воркеры, иначе старые процессы продолжат работать на прежнем коде.

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

php.net подчёркивает: единственное полное решение — обновление. Меры ниже закрывают отдельные пути, но установку безопасной не делают.

Для CVE-2026-109618:

• memory_limit=-1, желательно так, чтобы приложение не могло переопределить его (php_admin_value в пуле FPM или конфиге Apache); проверьте, что ни пул, ни каталог, ни приложение не ставят конечный лимит обратно;

• небольшой post_max_size: 8M, если загрузок файлов нет, и 32M, если есть; upload_max_filesize держите ниже него;

• лимиты на уровне веб-сервера или прокси: размер запроса после декодирования, число полей, частей multipart, заголовков и глубина вложенности, причём и для запросов без пригодного Content-Length;

• лимит контейнера или cgroup как граница доступности, лучше с политикой, которая убивает только затронутый воркер; RLIMIT_AS и RLIMIT_DATA для этого не подходят.

Для CVE-2026-109619:

• session.upload_progress.enabled=0 в php.ini, пуле FPM или конфиге сервера, который применяется до разбора запроса, и перезапуск всех воркеров; ini_set() и .user.ini для этого не годятся;

• на PHP 8.5 дополнительно fatal_error_backtraces=0;

• уберите устаревшие или невалидные настройки, которые применяются на каждый запрос и выводят диагностику до инициализации (скрытие диагностики через error_reporting, display_errors или @ не помогает);

• исправьте фатальные ошибки и таймауты, до которых может дотянуться злоумышленник, в том числе в колбэках, обработке загрузок и импорта.

Итог

1. Выясните, какая сборка PHP отвечает на веб-запросы, и сравните её с порогами выше.

2. Обновитесь через пакеты вендора, а в Docker — собственной сборкой или готовым образом, и перезапустите все воркеры.

3. Пока не обновились — временные меры и лимиты на прокси, помня, что это лишь снижение риска.

Первоисточники: сводка на php.net, ChangeLog, advisory GHSA-w8hw-w9fx-j79w и GHSA-6wmf-4rv5-p3rp, NVD CVE-2026-109618, NVD CVE-2026-109619, CERT-EU 2026-018.