PHP2Shell CVE-2026-109618 и 109619 в Docker: как обновить PHP в контейнерах, Nextcloud и mailcow

На 21 октября 2026 года исправления PHP2Shell (CVE-2026-109618 и 109619) вышли в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, но apt на хосте контейнеры не лечит: нужен новый образ и пересозданный контейнер. Версию проверяйте командой docker exec имя php -v. Образы на Docker Hub появляются с задержкой, теги 8.5.12RC1 и 8.4.27RC1 исправления не содержат, а статус образов Nextcloud AIO и mailcow не подтверждён — проверяйте у вендора.

Что известно на 21 октября 2026 и что проверять заново

21 октября 2026 года вышли исправления для двух критических уязвимостей ядра PHP — CVE-2026-109618 и CVE-2026-109619, вместе их называют PHP2Shell. Обе оценены в 9.2 по CVSS v4.0, эксплуатируются из сети без аутентификации, конфигурация по умолчанию уязвима. Исправлены ветки PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для 8.1 и старше официального исправления нет. Общий обзор и первый час работы — в статье что делать в первый час после выхода CVE-2026-109618 и 109619, здесь разбираем только контейнеры.

Docker добавляет к проблеме отдельный слой. PHP в контейнере — это не пакет хоста: apt upgrade или dnf update на сервере его не затрагивают, потому что внутри образа свой набор файлов, собранный на момент создания образа. Админ видит на хосте свежий php8.3-fpm, радуется, а контейнер с PHP 8.4.26 продолжает принимать запросы. Чаще всего так и бывает у компаний, где часть сервисов «живёт на хосте», а часть «поднял когда-то через compose и забыл».

Теперь про то, что на 21 октября не подтверждено. Из официальных образов известно только следующее: исправление добавлено в репозиторий docker-library/php, но на Docker Hub образ появляется после отдельного запроса в official-images и сборки, поэтому теги с 8.5.12 и 8.4.27 могут появиться не сразу. Теги 8.5.12RC1 и 8.4.27RC1 исправления не содержат. Заявлений по Nextcloud AIO, mailcow, образам Bitnami и другим сборкам приложений на момент проверки найти не удалось, поэтому статус конкретных образов на 21.10 не подтверждён: проверяйте на странице вендора и в самом образе командами ниже. Мы не пишем «образ X уже обновлён» — только как проверить это самим.

Что делаем мы у клиентов: сначала инвентаризация (какие контейнеры с PHP вообще есть), затем проверка версии внутри каждого, затем обновление образа и пересоздание контейнера, затем повторная проверка и мониторинг. Для задач, где образа с исправлением ещё нет, ставим временные меры, понимая, что они не заменяют обновление. Если на сервере остался образ с PHP 8.1 или старше, официального исправления нет, и этот вопрос решается миграцией на поддерживаемую ветку.

Как узнать версию PHP внутри всех контейнеров

Начинаем со списка запущенных контейнеров и образов. Из него сразу видно, где PHP ожидаем: официальные php:*-fpm и php:*-apache, образы приложений (Nextcloud, Roundcube, phpMyAdmin, WordPress, GLPI, Zabbix web), собственные образы разработчиков. Остановленные контейнеры тоже стоит посмотреть: docker ps -a — их кто-нибудь запустит после перезагрузки сервера.

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
docker ps -a --format '{{.Names}}\t{{.Image}}\t{{.Status}}' | grep -i Exited

Для одного контейнера версия узнаётся так: docker exec имя_контейнера php -v. Если контейнер крутит только FPM, бинарь php в нём всё равно есть в официальных образах. А вот в урезанных образах (alpine-сборки приложений, distroless) CLI может отсутствовать — тогда смотрим php-fpm -v или версию из метки образа. Скрипт-обход по всем запущенным контейнерам:

for c in $(docker ps --format '{{.Names}}'); do
  v=$(docker exec "$c" sh -c 'php -r "echo PHP_VERSION;" 2>/dev/null || php-fpm -v 2>/dev/null | head -1' 2>/dev/null)
  printf '%-40s %s\n' "$c" "${v:-no-php}"
done

Скрипт даёт «no-php» и для контейнеров без PHP, и для тех, где docker exec не сработал (нет оболочки sh). Такие позиции не отбрасываем, а разбираем руками: образ без sh с PHP внутри тоже уязвим. Если на сервере несколько проектов compose, добавьте в вывод метку проекта: docker inspect -f '{{index .Config.Labels "com.docker.compose.project"}}' имя. Это помогает потом понять, чей именно образ пересобирать.

Следующий шаг — дата сборки и источник образа. Версия PHP говорит, что внутри, а дата создания и digest показывают, когда образ собирали и совпадает ли он с тем, что сейчас лежит в реестре. Исправленные версии вышли 21 октября 2026 года, поэтому образ, созданный раньше этой даты, исправления содержать не может.

docker image inspect --format '{{.Created}}  {{index .RepoDigests 0}}' php:8.4-fpm
docker images --digests --format 'table {{.Repository}}\t{{.Tag}}\t{{.Digest}}\t{{.CreatedSince}}'

Важная деталь: поле Created у образа — дата сборки образа, а не дата скачивания. Ещё одна типичная ошибка — проверить версию командой docker run --rm php:8.4-fpm php -v, не сделав docker pull: Docker возьмёт локальную копию, и вы увидите старую версию (или, хуже, убедитесь в версии, которой уже нет в реестре). Сначала docker pull php:8.4-fpm, потом проверка. Если после pull версия всё ещё прежняя — значит, образ с исправлением на Hub пока не опубликован, и это нормально для первых часов.

Отдельная категория — контейнеры, где версия PHP зафиксирована в имени тега: php:8.4.26-fpm или FROM php:8.3.35-apache в Dockerfile. Такой тег не сдвинется сам, сколько ни тяни pull: надо править номер в Dockerfile или compose-файле. Поищите по всем репозиториям с инфраструктурой: grep -rnE 'php:[0-9]|FROM .*php' --include=Dockerfile* --include=*.yml --include=*.yaml .. Образы приложений в списке находок тоже учитываем: PHP в них стоит в виде слоя базового образа, и его версию определяет тот, кто собрал образ приложения.

Почему apt и dnf на хосте не лечат контейнеры

Контейнер использует ядро хоста, но файловая система у него своя — из слоёв образа. Библиотеки, бинарь php и php-fpm внутри образа не зависят от пакетов, установленных на сервере. Обновили на хосте php8.3-fpm по рекомендации из статьи про Debian и Ubuntu с Sury и PPA — это защитит сервисы, работающие на хосте, но ни одного контейнера не коснётся.

Вторая ловушка — попытка «обновить внутри». Зайти в контейнер и выполнить apt-get upgrade бессмысленно по двум причинам. Во-первых, в официальных образах PHP собран из исходников, а не поставлен пакетом из репозитория Debian, поэтому apt внутри образа новую версию интерпретатора не принесёт. Во-вторых, всё, что вы изменили внутри работающего контейнера, пропадает при его пересоздании: docker compose up -d --force-recreate, обновление образа или перезапуск через оркестратор вернут слой из образа.

Третья — не перезапущенные процессы. Даже после того как вы подтянули новый образ командой docker pull, работающий контейнер продолжает использовать старый, пока не будет создан заново. Простой docker restart тоже не помогает: он перезапускает контейнер из тех же слоёв. Обновление образа вступает в силу только при пересоздании контейнера — docker compose up -d для сервисов, у которых образ изменился, или --force-recreate для принудительного пересоздания.

Таблица ниже — что именно лечит каждое действие. Мы показываем её клиентам на планёрке, потому что именно здесь чаще всего возникает ложное чувство безопасности.

Отдельно про образы приложений. Если приложение (например Nextcloud) в образе идёт со своим PHP, то обновление самого приложения через его встроенный механизм PHP не трогает: версия интерпретатора определяется образом. Об этом мы подробно пишем в разделе про Nextcloud и mailcow ниже.

Обновляем официальные и самосборные образы

Алгоритм для образов на базе официальных php:*-fpm и php:*-apache. Сначала убеждаемся, что исправленный образ уже на Docker Hub: делаем pull и смотрим версию. Если версия новая — пересобираем свои образы и пересоздаём контейнеры. Если нет — ждём, ставим временные меры (раздел ниже) и повторяем проверку в течение дня: образ появляется на Hub после отдельного PR в official-images и сборки, то есть с задержкой относительно публикации исходников.

docker pull php:8.4-fpm
docker run --rm php:8.4-fpm php -v
docker image inspect --format '{{.Created}}' php:8.4-fpm

Для самосборных образов добавляем флаги --pull и --no-cache. --pull заставляет Docker заново запросить базовый образ из реестра, а не использовать локальную копию. --no-cache не даёт использовать закэшированные слои: если слой с установкой расширений уже есть в кэше, он переиспользуется, даже когда базовый образ сменился. Для небольших образов лишняя пересборка стоит минуты, а для крупных можно ограничиться --pull — но тогда внимательно проверьте итоговую версию.

docker build --pull --no-cache -t registry.example/app-php:2026-10-21 .
docker run --rm registry.example/app-php:2026-10-21 php -v

Для проектов на compose последовательность такая: обновить образы, пересоздать контейнеры и проверить. Флаг --force-recreate по документации Docker пересоздаёт контейнеры, даже если их конфигурация и образ не менялись, — удобно, когда вы добавили ini-файл или переменные окружения. Если в compose сервис собирается из Dockerfile, добавьте --build и при необходимости build --pull.

docker compose pull
docker compose build --pull
docker compose up -d --force-recreate
docker compose exec php php -v

Заметьте: имя сервиса в последней команде — «php» — замените на своё. Для проектов с одним сервисом, который требует длительного простоя, пересоздавайте контейнеры по очереди: docker compose up -d --force-recreate --no-deps имя_сервиса. Флаг --no-deps не трогает связанные сервисы, и вы не перезапустите заодно базу.

Что проверять после пересоздания. Первое — версия PHP внутри нового контейнера. Второе — что контейнер действительно поднялся из нового образа: сравните ID образа в docker ps с docker images. Третье — работоспособность приложения: загрузка файла, вход, фоновые задачи. И четвёртое — старые образы: docker image prune уберёт неиспользуемые, но делайте это осознанно, оставив один предыдущий образ на случай отката. Откат на уязвимый образ — решение временное, запишите срок.

Если в Dockerfile закреплён точный тег (php:8.4.26-fpm), поменяйте его на исправленный (8.4.27-fpm) только после того, как такой тег реально появился на Hub: проверьте docker pull php:8.4.27-fpm. Теги 8.5.12RC1 и 8.4.27RC1 — не то, что вам нужно: они исправления не содержат. А вот закрепление точной версии вообще хорошая практика, потому что обновление становится осознанным действием, а не побочным эффектом пересборки. Про учёт образов и инвентаризацию окружения мы пишем в статье про инвентаризацию IT-активов, а про разворачивание приложений в Docker — в разборе установки Snipe-IT в Docker.

Nextcloud, mailcow, Bitnami и другие образы приложений

У образов приложений своя схема обновления: PHP в них поставляет сборщик образа, и вы получаете новую версию интерпретатора только вместе с новым образом приложения. По данным Sansec, Nextcloud 35.0.1 и Roundcube 1.7.4 уязвимы к RCE без входа — это следствие бага в интерпретаторе, а не приложения. Заявлений от Nextcloud и mailcow об исправленных образах на 21 октября 2026 года мы не нашли, поэтому статус на 21.10 не подтверждён: смотрите страницы вендоров и проверяйте версию в самом контейнере.

Nextcloud All-in-One. Приложение работает в контейнере nextcloud-aio-nextcloud, управляет им мастер-контейнер nextcloud-aio-mastercontainer. Версию PHP смотрим так: docker exec nextcloud-aio-nextcloud php -v. Обновление по официальной документации AIO идёт через интерфейс мастер-контейнера: когда в реестре появляются новые образы, интерфейс показывает, что доступны обновления контейнеров; нужно нажать «Stop containers», затем «Start and update containers». Перед этим делаем резервную копию встроенным механизмом AIO. Для самого мастер-контейнера процедура отдельная: после остановки контейнеров появляется кнопка обновления мастер-контейнера. Вручную docker pull отдельных контейнеров AIO не делаем: схему обновления определяет мастер-контейнер, имя которого, по документации, менять нельзя.

Если Nextcloud развёрнут не через AIO, а как образ nextcloud:fpm или nextcloud:apache (этот образ основан на официальном образе PHP), порядок обычный: docker compose pull, docker compose up -d, затем php -v внутри. Встроенное обновление Nextcloud через веб-интерфейс версию PHP не меняет. Выбирая образ, смотрите, какая версия PHP зашита в конкретный тег: у Nextcloud теги с версией приложения, а PHP определяется базовым образом.

mailcow-dockerized. PHP-FPM у mailcow работает в контейнере php-fpm-mailcow: он обслуживает веб-интерфейс администрирования mailcow (и дополнения вроде Roundcube, если вы их включали). SOGo — отдельный контейнер sogo-mailcow, это не PHP. Проверка: docker exec $(docker ps -qf name=php-fpm-mailcow) php -v. Обновляется mailcow штатным скриптом из каталога установки: cd /opt/mailcow-dockerized && ./update.sh (путь у вас может быть другим). Скрипт сам останавливает и пересоздаёт контейнеры, поэтому планируйте окно: почта на время обновления недоступна. Отдельно образ php-fpm-mailcow командой docker pull не трогаем — обновляем mailcow целиком, как предписано его документацией.

Если установка mailcow старая, вспомните два практических момента из релиз-заметок проекта: при Docker Compose v5 перед обновлением нужно один раз выполнить git fetch и git checkout origin/master update.sh, иначе скрипт обновления может не отработать. И второй: для режима проверки есть ключ --check (в копиях скрипта, которые мы видели, код возврата 0 означает «обновление есть», 3 — «обновлений нет»). Перед использованием в мониторинге проверьте это по вашей версии update.sh и странице обновления в документации mailcow.

Bitnami и прочие готовые образы. Для образов Bitnami (например, bitnami/wordpress или bitnami/phpmyadmin) PHP идёт внутри образа приложения. Уточните на странице образа, какой тег содержит исправленный PHP и поддерживается ли образ вообще — этот статус на 21.10 мы не подтверждаем. Тот же подход для любого стороннего образа: версия из php -v, дата из docker image inspect, ссылка на вендора. Если вендор молчит, а образ публичный и открыт в интернет, применяйте временные меры, а при возможности пересоберите образ на исправленной базе сами.

Отдельно напомним про контейнеры, которые «случайно» оказались в инфраструктуре: тестовые стенды разработчиков, демо-версии, образы phpMyAdmin и Adminer, поднятые на время. Они, как правило, смотрят в интернет, обновлять их забывают, и именно их проще всего найти сканером. Если они не нужны — остановите. Если нужны — обновите вместе с остальными. Подробнее про другие PHP-приложения со своим веб-интерфейсом — в статье про Zabbix, GLPI и FreePBX.

• Nextcloud AIO — версия: docker exec nextcloud-aio-nextcloud php -v; обновление через интерфейс мастер-контейнера, после резервной копии
• mailcow — версия: docker exec в php-fpm-mailcow; обновление скриптом update.sh в каталоге установки
• nextcloud:fpm / nextcloud:apache — docker compose pull и up -d, затем php -v
• Bitnami и сторонние образы — проверить статус на странице вендора, версию и дату в самом образе

Временные меры для контейнеров, пока нет исправленного образа

Если исправленного образа ещё нет или обновить приложение сейчас нельзя, ставим частичные меры. Это не замена обновлению: по оценке Джины Питер Банярд из команды PHP, надёжных обходных мер нет, единственное настоящее исправление — патч. Тем не менее меры уменьшают поверхность. Все они применяются так, чтобы приложение не могло их переопределить: через php.ini или конфиг пула, а не через ini_set() и не через .user.ini.

Основная мера — ini-файл, смонтированный в контейнер. В официальных образах PHP дополнительные ini читаются из каталога /usr/local/etc/php/conf.d/. Создаём файл и подключаем его томом только на чтение. После изменения контейнер нужно пересоздать, чтобы перезапустились все воркеры.

cat > php-hardening.ini <<'EOF'
session.upload_progress.enabled = 0
EOF

services:
  php:
    image: php:8.4-fpm
    volumes:
      - ./php-hardening.ini:/usr/local/etc/php/conf.d/zz-hardening.ini:ro

Для PHP 8.5 дополнительно добавьте fatal_error_backtraces = 0. Параметр memory_limit = -1 рекомендует Sansec как способ не допускать исчерпания памяти, с которого начинается эксплуатация, но у него есть цена: один запрос может съесть всю память сервера, поэтому в контейнере обязательно задайте лимит памяти самого контейнера (mem_limit в compose или --memory в docker run) и следите за потреблением RAM. Patchstack для CVE-2026-109618 советует задавать memory_limit=-1 через php_admin_value (приложение его не переопределит), post_max_size держать в пределах 8M без загрузок и 32M с загрузками, upload_max_filesize — ниже, а размер запроса, число полей и multipart ограничивать на веб-сервере или прокси. Не используйте RLIMIT_AS и RLIMIT_DATA.

Для PHP-FPM в контейнере то же самое можно сделать на уровне пула: дополнительный файл в /usr/local/etc/php-fpm.d/ с секцией вашего пула и директивами php_admin_flag[session.upload_progress.enabled] = off и php_admin_value[memory_limit] = -1. Проверьте, как называется пул в вашем образе (чаще всего www) и не перезаписывает ли образ ваш файл. Затем пересоздайте контейнер и убедитесь, что настройка действительно применена: docker exec имя php -i | grep upload_progress.enabled покажет значение CLI-конфигурации, а для пула проверяйте через тестовую страницу phpinfo во временном окружении, но не на боевом сайте.

Меры на уровне прокси. Если перед контейнером стоит nginx или другой обратный прокси, можно запретить multipart/form-data. По рекомендации Sansec это делается в nginx правилом if ($http_content_type ~* "multipart/form-data") { return 403; }. Предупреждаем: так сломаются загрузки файлов и часть форм (корзина, оформление заказа), поэтому после включения обязательно проверьте реальный заказ или загрузку. Режимы обслуживания CMS не помогают: PHP разбирает multipart-тело раньше кода приложения. Подробнее про блокировку и проверку логов — в статье про признаки эксплуатации в логах nginx и Apache.

Если контейнер не обязателен — остановите его: docker stop. Это единственная мера, которая полностью закрывает риск. Если вы используете Cloudflare, аварийные WAF-правила доступны на всех тарифах, но работают только когда origin принимает трафик исключительно от Cloudflare; это тоже временная мера. Никаких «плагинов-заплаток» и сниппетов с форумов ставить не надо: Patchstack прямо предупреждает об этом.

Мини-кейс, мониторинг и ошибки

Условный пример. В стартапе «КодЛесопилка» 11 рабочих мест, один Docker-хост с compose-проектами: веб-приложение на php:8.3-fpm за nginx, внутренний Nextcloud и почта на mailcow. Админа настораживает фраза «на хосте PHP обновлён». Подход: делаем обход по контейнерам скриптом из раздела выше, для каждого фиксируем версию и дату образа, для приложения на php-fpm проверяем наличие тега с 8.3.36, для Nextcloud и mailcow смотрим страницы вендоров и штатные механизмы обновления. Пока исправленного образа нет, ставим ini-файл с отключённым upload_progress и ограничением памяти контейнера, затем возвращаемся к проверке образа каждые несколько часов. Это иллюстрация подхода, а не отчёт о результатах.

Мониторинг. Одной проверки мало: образы обновляются, контейнеры пересоздаются, разработчики приносят новые. Простой вариант — скрипт по cron, который сравнивает версию PHP во всех контейнерах с минимально допустимой и отправляет оповещение при несовпадении. Минимальные версии берём из исправленных веток: 8.5.12, 8.4.27, 8.3.36, 8.2.35. Скрипт ниже сравнивает по ветке; для остальных веток (8.1 и старше) оповещает всегда, потому что исправления нет.

#!/bin/bash
# проверка версий PHP во всех запущенных контейнерах
fixed() { case "${1%.*}" in 8.5) echo 8.5.12;; 8.4) echo 8.4.27;; 8.3) echo 8.3.36;; 8.2) echo 8.2.35;; *) echo 99.0.0;; esac; }
for c in $(docker ps --format '{{.Names}}'); do
  v=$(docker exec "$c" php -r 'echo PHP_VERSION;' 2>/dev/null) || continue
  need=$(fixed "$v")
  if [ "$(printf '%s\n%s\n' "$need" "$v" | sort -V | head -1)" != "$need" ]; then
    echo "УЯЗВИМ: $c PHP $v (нужно не ниже $need)"
  fi
done

Скрипт мы кладём в cron раз в час и подключаем вывод к оповещениям (почта, Telegram или триггер в системе мониторинга). Версию вида 8.4.27-dev или с суффиксом RC он тоже может отнести к неверным: тег RC исправления не содержит, и такие образы лучше разбирать вручную. В мониторинге также полезно следить за признаками из рекомендаций Patchstack — необычные multipart-запросы с последующей ошибкой memory_limit, повторяющиеся HTTP 500, аномально большие или битые куки PHPSESSID, необъяснимые перезапуски воркеров PHP. Это не доказательство ни в ту, ни в другую сторону, но повод посмотреть логи. Для контейнеров смотрим docker logs --since 24h имя и docker inspect -f '{{.RestartCount}}' имя.

Если признаки есть. Обновляем, считаем сервер возможно скомпрометированным и ничего не успокаиваем «пока». Список секретов, которые хранились в контейнере или были доступны приложению (ключи API, пароли баз, токены, приватные ключи TLS), мы передаём владельцу на ротацию; пароли живых учёток сами не меняем — решение о смене принимает владелец системы. Утечка памяти воркера, по описанию Sansec, может отдавать именно такие данные.

Типичные ошибки, которые мы видим. Первая: обновили хост и считают контейнеры закрытыми. Вторая: сделали docker pull и забыли пересоздать контейнер. Третья: сделали docker restart, ожидая обновления. Четвёртая: взяли тег RC. Пятая: проверили версию, не сделав pull, и поверили в локальный кэш. Шестая: включили блокировку multipart на прокси и не проверили загрузку файлов. Седьмая: оставили в compose точный старый тег. Восьмая: забыли про остановленные контейнеры и «временные» стенды. Если у вас много Docker-хостов или нет времени разбираться — это наша ежедневная работа в рамках обслуживания и внедрения open source решений. Базовая последовательность действий для всех типов серверов описана в нашем материале про первый час, а для хостов с панелями и несколькими версиями PHP — в статье про HestiaCP, ISPmanager и несколько версий PHP.

Частые вопросы