Пачване на PHP в Docker контейнери

Накратко: Актуализацията на PHP Docker образ е задължителна срещу PHP2Shell и не става от само себе си. Трябва да изградите или изтеглите образа наново с поправена PHP версия, да създадете всеки контейнер наново от него и да проверите, че в работещия контейнер работи 8.5.12, 8.4.27, 8.3.36 или 8.2.35. Обикновено рестартиране на контейнера не стига.

Защо контейнерите не са сигурни автоматично

Docker образът е замразена моментна снимка. PHP в него остава на състоянието, което е имал при изграждането, дори на хоста отдавна да са внесени актуализации. Актуализация на пакет на хост системата не променя нищо в PHP в контейнера.

Към това се добавят типични клопки: образи, изградени преди месеци и оттогава недокосвани, базови образи с фиксиран таг като php:8.3.35-fpm, локални кешове, които при изграждането използват повторно стария базов образ, и контейнери, които са рестартирани, но никога не са създавани наново. Засегнати са всички режими на работа, обичайни в контейнерите: PHP-FPM, Apache с mod_php и FrankenPHP.

Добавя се и въпрос за отговорността. В много фирми агенция или разработчик е изградил образа веднъж, а го експлоатира вътрешният ИТ отдел или хостинг доставчик. Тогава никой не се чувства отговорен за състоянието на PHP в образа. Затова първо изяснете кой изгражда образа, къде е Dockerfile и кой има право да внедрява нови образи.

Проверка на PHP версията в контейнера

Проверете работещия контейнер, а не само Dockerfile. Командите са само за четене.

docker ps --format "table {{.Names}}\t{{.Image}}\t{{.CreatedAt}}"
docker exec <container> php -v
docker exec <container> php -i | grep -E "^PHP Version|Server API"
docker image inspect <image> --format "{{.Created}}"

Ако образът ползва пакети от дистрибуция вместо официални PHP билдове, проверете състоянието на пакета в контейнера. Имената на пакетите се различават според базовата дистрибуция:

docker exec <container> sh -c "apt policy php8.3-fpm 2>/dev/null || apk info -v 2>/dev/null | grep php"

При пакети от дистрибуции може да е внесен backport, въпреки че номерът на версията остава стар. Тогава значение има changelog-ът на пакета. Официалните PHP образи, напротив, носят PHP най-често компилиран сами; там номерът на версията от php -v е меродавната стойност. Как да разпознавате backport-ове, описва страницата Как да проверите правилно PHP версията и състоянието на пача.

Актуализация на PHP Docker образ: изграждане наново и внедряване

Собствен образ на базата на PHP образ: изтеглете наново базовия образ и изградете без кеш.

docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v      # проверете версията преди разгръщането

С Docker Compose: изтеглете, респективно изградете образите и създайте контейнерите наново.

docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreate

След това проверете отново с docker exec <container> php -v дали работи новата версия. Ако контейнерът има фиксиран таг на версията в Dockerfile, например FROM php:8.3.35-fpm, трябва да повишите тага. Таг към клона, като php:8.3-fpm, получава нови състояния на пачовете, но само ако изтеглите наново.

Дръжте предишния образ наличен, докато новата версия бъде тествана. При грешка така можете да се върнете, без да оставяте приложението дълго офлайн. Старият образ обаче отново съдържа уязвимия PHP; затова връщането е допустимо само за кратко и с временните мерки.

Който работи с Kubernetes, внедрява новия образ през Deployment. Подробности има на страницата Пачване на PHP в Kubernetes. За образи с FrankenPHP важи същият начин; бележки за режима на работа ще намерите на страницата Защита на FrankenPHP.

Временни мерки в контейнера

Ако актуализацията още не е възможна, временните мерки на php.net важат и в контейнера. Те не са пълна защита. Ограничението на паметта се задава при това на контейнера, защото php.net го препоръчва чрез контейнер или cgroup, а не чрез RLIMIT_AS или RLIMIT_DATA:

; напр. като файл в образа: /usr/local/etc/php/conf.d/zz-uebergang.ini
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 6M
session.upload_progress.enabled = 0

docker run --memory=1g ...         # или в Compose: deploy.resources.limits.memory

Стойността нагласете според Вашето приложение. Внимавайте приложението да не може само да презапише memory_limit; при PHP-FPM задавате стойностите за това в пула с php_admin_value. Новата конфигурация действа едва когато контейнерът е създаден наново или рестартиран; основите за рестартирането са на страницата Рестартиране на PHP-FPM и на всички worker процеси.

За да върви по-бързо следващия път

• Изграждайте образите редовно и автоматично наново, не само при промени в кода.
• Ползвайте базови образи с таг на клона и версионирайте изградено състояние с дата или digest.
• Преди внедряване проверявайте образите за известни уязвимости и експлоатирайте контейнерите без root права.
• Водете опис кои контейнери кой образ ползват.

Как помага PHP SOS конкретно?

• Описване на състоянието: Проверяваме всички работещи контейнери, техните образи и PHP версии, също и спомагателните контейнери и staging.
• Изграждане наново и внедряване: Чрез услугата за пач на PHP изграждаме образите с поправена версия и създаваме контейнерите наново контролирано.
• Осигуряване на прехода, където актуализацията зависи от приложението: стойностите на php.net, ограничение на паметта на контейнера.
• Постоянно наблюдение: С наблюдението на сигурността държим под око състоянията на образите и необичайното поведение на контейнерите.

Често задавани въпроси

Източници

• php.net: Съобщения за сигурност
• PHP 8 ChangeLog
• OWASP Cheat Sheets