Накратко: В Kubernetes PHP е в контейнерния Image, а не в клъстера. След PHP2Shell трябва да изградите наново всеки Kubernetes PHP Image с коригирана версия на PHP, да внедрите наново всички засегнати Workload и след това да проверите състоянието във всеки работещ Pod. Актуализиран базов Image в Registry сам по себе си не променя нищо в работещите Pod.
Защо самият клъстер не пачва
Kubernetes управлява контейнери, но не се грижи за софтуера в тях. Всеки Pod работи с Image, от който е стартиран, докато не бъде заменен. Който експлоатира PHP приложения в клъстера, носи затова отговорността за Image, дори клъстерът да работи като управлявана услуга при облачен доставчик. Доставчикът поддържа обикновено управляващата равнина и възлите, а не Image на клиентите.
PHP2Shell обхваща CVE-2026-109618 и CVE-2026-109619, и двете с CVSS v4.0 9,2. Засегнати са, наред с други, PHP-FPM, Apache с mod_php и FrankenPHP, т.е. обичайните режими на работа в PHP Image. Коригирани са PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35.
Опис на наличното: кой Kubernetes PHP Image къде работи?
Започнете със списък на всички Image в клъстера. Следващите команди само четат. Имената на Namespace, Deployment и контейнери са примери.
# Всички Image на всички Pod, групирани
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'
# Действително работещ Digest на Image за всеки контейнер
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'
# Версия на PHP в работещ Pod
kubectl exec -n shop deploy/web -c php -- php -v
Освен Deployment мислете и за StatefulSet, DaemonSet, CronJob и Init контейнери. В по-големи клъстери помагат скенери на Image, които претърсват Image за известни CVE. За пакетите на дистрибуции в Image важи както навсякъде: бекпортът може да остави номера на версията непроменен, тогава от значение е дневникът на промените на пакета.
Ново изграждане на Image
Първо актуализирайте базовия Image. Ако ползвате официални PHP Image, изберете вариант с коригирана версия на PHP. После изградете наново собствения си Image, без да вземате старата базова слой от кеша.
# Пример: ново изграждане на Image, активно ново изтегляне на базовия Image
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .
# Проверка на версията на PHP в новия Image преди Rollout
docker run --rm registry.example.com/shop/web:2026-10-25 php -v
Не разчитайте на тагове като latest или на просто основна версия. Реферирайте в манифеста по възможност Digest на новия Image, за да е ясно кое състояние се внедрява. Ако внедряването върви през GitOps или Helm, променете Image там, за да не се върне състоянието при следващото сверяване.
Rollout и проверка
Нов Rollout заменя всички Pod на даден Workload стъпка по стъпка. След това проверявате състоянието в работещите Pod. Едва тогава пачът е в сила, защото новите файлове помагат само ако старите PHP процеси вече не работят.
# Rollout с нов Image (имената са пример)
kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256:<digest>
kubectl -n shop rollout status deploy/web
# Проверка: всички Pod ли са рестартирани, активен ли е новият Digest?
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v
Ако Image е изпратен наново под същия таг, kubectl rollout restart предизвиква рестарт; Pod обаче изтеглят Image наново само ако imagePullPolicy го предвижда. По-сигурна е смяната към нов Digest.
Запазете логовете, преди да замените Pod. Със стария Pod изчезват и локалните му протоколи. Запазете логовете на уеб сървъра и на приложенията от 20.10.2026 г. нататък, в идеалния случай в централна платформа за логове.
Временни мерки в клъстера
Ако за Вашата версия на PHP още няма наличен коригиран Image, php.net препоръчва временни мерки без пълна защита. В клъстера задавате ограничения на паметта чрез лимитите на ресурсите на контейнерите, които се основават на cgroups. Това съответства на препоръката паметта да се ограничава чрез контейнери или cgroups, а не чрез RLIMIT_AS или RLIMIT_DATA.
; php.ini или FPM пул в Image, напр. включен чрез ConfigMap
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
При функция за качване php.net посочва post_max_size = 32M. При PHP 8.5 се добавя fatal_error_backtraces=0. След промяна на конфигурацията е нужен нов Rollout. Допълнително NetworkPolicy ограничават изходящите връзки на PHP Pod, а Ingress със защитни правила може да затрудни опитите за атака. Правила само по данните на заявката обаче според Cloudflare не са достатъчни.
Трайно по-добра подредба
Планирайте редовни автоматични нови изграждания на всички PHP Image, проверка на Image във веригата за изграждане и политики, които допускат само подписани или проверени Image. Ако PHP контейнерите работят с потребител без root права и със защитена от запис файлова система, щетите от успешна атака намаляват. Указания за отделни контейнери има в Пач на PHP в Docker контейнери, а за FrankenPHP в Как да обезопасите FrankenPHP.
В много клъстери PHP приложенията не работят самостоятелно. Често има Sidecar контейнери за логове или метрики, помощни Image за миграции на бази данни и задачи, които стартират само нощем. И Image на външни доставчици, например за уики, интерфейс за наблюдение или система за заявки, могат да съдържат PHP, без това да личи от името. Затова проверявайте не само собствените си приложения, а всеки Image в клъстера. За чужди Image важи: изчакайте актуализирана версия от производителя, проверете данните му за вградената версия на PHP и ограничете достъпността, докато я няма. Ако такава система работи само вътрешно, това намалява риска, но не замества актуализацията.
Как помага PHP SOS конкретно?
- Описваме всички Workload с PHP, техните Image и Digest и проверяваме версията на PHP в работещите Pod.
- Чрез услугата за PHP пач изграждаме Image наново, внедряваме ги и документираме състоянието за всеки Workload.
- Запазваме логовете преди смяната и проверяваме за следи от атака.
- Със следене на сигурността и автоматизирани нови изграждания гарантираме, че следващият пач ще стига по-бързо до клъстера.
Често задавани въпроси
Достатъчно ли е да се актуализира базовият Image в Registry?
Не. Работещите Pod продължават да ползват Image, с който са стартирани. Едва нов Rollout с наново изградения Image заменя Pod. След това проверете версията на PHP във всеки работещ Pod.
Защо Image да се реферират чрез Digest?
Един таг може да сочи към различни състояния на Image, според това кога е изтеглен. Digest назовава точно едно състояние. Така знаете със сигурност кой код в кой Pod работи, а Rollout стават проследими.
Какво да е с CronJob и Init контейнерите?
И те могат да съдържат PHP и са част от описа на наличното. CronJob стартират при всяко изпълнение нови Pod от своя шаблон; затова актуализирайте Image в шаблона. Init контейнерите работят при старта на всеки Pod.
Защитава ли NetworkPolicy от PHP2Shell?
Не затваря уязвимостта, но може да ограничи щетите. Който ограничава изходящите връзки на PHP Pod, затруднява презареждането на зловреден код и движението встрани в клъстера.