Záplatování PHP v Kubernetes

Stručně: V Kubernetes sídlí PHP v image kontejneru, ne v clusteru. Po PHP2Shell musíte každou image PHP v Kubernetes znovu sestavit s opravenou verzí PHP, znovu nasadit všechny dotčené workloady a poté v každém běžícím podu zkontrolovat stav. Aktualizovaná základní image v registry sama na běžících podech nic nemění.

Proč cluster sám nezáplatuje

Kubernetes spravuje kontejnery, ale o software v nich se nestará. Každý pod běží s image, ze které byl spuštěn, dokud není nahrazen. Kdo v clusteru provozuje aplikace PHP, nese proto odpovědnost za image, i když cluster běží jako spravovaná služba u poskytovatele cloudu. Poskytovatel zpravidla pečuje o řídicí rovinu a uzly, nikoli o image zákazníků.

PHP2Shell zahrnuje CVE-2026-109618 a CVE-2026-109619, každou s CVSS v4.0 9,2. Postiženy jsou mimo jiné PHP-FPM, Apache s mod_php a FrankenPHP, tedy obvyklé provozní režimy v image PHP. Opraveny jsou PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35.

Inventura: která image PHP v Kubernetes kde běží?

Začněte seznamem všech image v clusteru. Následující příkazy jen čtou. Názvy namespace, deploymentů a kontejnerů jsou příklady.

# Všechny image všech podů, seskupeně
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'

# Skutečně běžící digest image pro každý kontejner
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'

# Verze PHP v běžícím podu
kubectl exec -n shop deploy/web -c php -- php -v

Vedle deploymentů myslete i na StatefulSety, DaemonSety, CronJoby a init kontejnery. Ve větších clusterech pomáhají skenery image, které image prohledávají na známá CVE. U balíčků distribuce uvnitř image platí jako všude: backport může nechat číslo verze beze změny, pak rozhoduje changelog balíčku.

Znovu sestavit image

Nejdřív aktualizujte základní image. Používáte-li oficiální image PHP, zvolte variantu s opravenou verzí PHP. Poté sestavte vlastní image znovu, aniž byste přebírali starou základní vrstvu z cache.

# Příklad: znovu sestavit image, základní image aktivně stáhnout znovu
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .

# Zkontrolovat verzi PHP v nové image před rolloutem
docker run --rm registry.example.com/shop/web:2026-10-25 php -v

Nespoléhejte na tagy jako latest nebo pouhou hlavní verzi. V manifestu se pokud možno odkazujte na digest nové image, aby bylo jednoznačné, jaký stav se nasazuje. Pokud nasazení probíhá přes GitOps nebo Helm, změňte image tam, aby se stav při příštím porovnání nevrátil zpět.

Rollout a kontrola

Nový rollout postupně nahradí všechny pody workloadu. Poté zkontrolujte stav v běžících podech. Teprve pak je záplata účinná, protože nové soubory pomáhají jen tehdy, když už neběží staré procesy PHP.

# Rollout s novou image (názvy jako příklad)
kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256:<digest>
kubectl -n shop rollout status deploy/web

# Kontrola: všechny pody restartovány, aktivní nový digest?
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v

Pokud byla image znovu nahrána pod stejným tagem, kubectl rollout restart vyvolá restart; pody ale image stahují znovu jen tehdy, když to předpokládá imagePullPolicy. Bezpečnější je přechod na nový digest.

Přechodná opatření v clusteru

Pokud pro vaši verzi PHP ještě není k dispozici opravená image, doporučuje php.net přechodná opatření bez úplné ochrany. V clusteru nastavte limity paměti přes limity prostředků kontejnerů, které vycházejí z cgroups. To odpovídá doporučení omezovat paměť přes kontejner nebo cgroups, a ne přes RLIMIT_AS nebo RLIMIT_DATA.

; php.ini nebo pool FPM v image, např. vložené přes ConfigMap
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

S funkcí nahrávání souborů uvádí php.net post_max_size = 32M. Na PHP 8.5 přibývá fatal_error_backtraces=0. Po změně konfigurace je nutný nový rollout. Doplňkově omezují NetworkPolicy odchozí spojení podů s PHP a Ingress s ochrannými pravidly může útoky ztížit. Pravidla jen na základě dat požadavku ale podle Cloudflare nestačí.

Dlouhodobě se lépe postavit

Naplánujte pravidelné automatické přestavby všech image PHP, kontrolu image v řetězci sestavení a zásady, které připustí jen podepsané nebo zkontrolované image. Pokud kontejnery PHP běží s uživatelem bez práv roota a s souborovým systémem chráněným proti zápisu, škody úspěšného útoku se snižují. Pokyny pro jednotlivé kontejnery najdete na stránce Záplatování PHP v kontejnerech Docker, pro FrankenPHP na stránce Zabezpečení FrankenPHP.

V mnoha clusterech neběží aplikace PHP osamoceně. Často existují sidecar kontejnery pro logování nebo metriky, pomocné image pro migrace databáze a joby, které startují jen v noci. I image třetích stran, například pro wiki, monitorovací rozhraní nebo ticketovací systém, mohou obsahovat PHP, aniž by to bylo z názvu poznat. Nekontrolujte proto jen vlastní aplikace, ale každou image v clusteru. U cizích image platí: počkejte na aktualizovanou verzi od výrobce, ověřte jeho údaje o obsažené verzi PHP a omezte dostupnost, dokud nebude k dispozici. Pokud takový systém běží jen interně, sníží to riziko, ale aktualizaci to nenahrazuje.

Jak konkrétně pomáhá PHP SOS?

• Zmapujeme všechny workloady s PHP, jejich image a digesty a zkontrolujeme verzi PHP v běžících podech.
• Prostřednictvím služby záplatování PHP znovu sestavíme image, nasadíme je a stav zdokumentujeme pro každý workload.
• Zajistíme logy před výměnou a zkontrolujeme stopy útoku.
• Pomocí bezpečnostního monitoringu a automatizovaných přestaveb zajistíme, aby se příští záplata dostala do clusteru rychleji.

Časté dotazy

Zdroje

• php.net: bezpečnostní oznámení
• PHP 8 ChangeLog
• OWASP Cheat Sheets
• BSI