Záplatovanie PHP v Kubernetes

Stručne: V Kubernetes sedí PHP v obraze kontajnera, nie v clustri. Po PHP2Shell musíte každý obraz PHP v Kubernetes znovu zostaviť s opravenou verziou PHP, nanovo nasadiť všetky dotknuté workloady a potom v každom bežiacom pode skontrolovať stav. Aktualizovaný základný obraz v registri sám na bežiacich podoch nič nemení.

Prečo cluster sám nezáplatuje

Kubernetes spravuje kontajnery, ale o softvér v nich sa nestará. Každý pod beží s obrazom, z ktorého bol spustený, kým nie je nahradený. Kto prevádzkuje aplikácie PHP v clustri, nesie preto zodpovednosť za obrazy, aj keď cluster beží ako spravovaná služba u poskytovateľa cloudu. Poskytovateľ typicky udržiava riadiacu rovinu a uzly, nie obrazy zákazníkov.

PHP2Shell zahŕňa CVE-2026-109618 a CVE-2026-109619, každá s CVSS v4.0 9.2. Dotknuté sú okrem iného PHP-FPM, Apache s mod_php a FrankenPHP, teda bežné režimy prevádzky v obrazoch PHP. Opravené sú PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35.

Inventúra: ktorý obraz PHP v Kubernetes beží kde?

Začnite zoznamom všetkých obrazov v clustri. Nasledujúce príkazy iba čítajú. Názvy namespace, deploymentov a kontajnerov sú príklady.

# Všetky obrazy všetkých podov, zoskupené
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'

# Skutočne bežiaci digest obrazu pre každý kontajner
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'

# Verzia PHP v bežiacom pode
kubectl exec -n shop deploy/web -c php -- php -v

Popri deploymentoch myslite aj na StatefulSety, DaemonSety, CronJoby a init kontajnery. Vo väčších clustroch pomáhajú skenery obrazov, ktoré obrazy prehľadávajú na známe CVE. Pri balíkoch distribúcie vnútri obrazu platí ako všade: backport môže nechať číslo verzie nezmenené, vtedy sa počíta changelog balíka.

Znovu zostavte obrazy

Najprv aktualizujte základný obraz. Ak používate oficiálne obrazy PHP, zvoľte variant s opravenou verziou PHP. Potom znova zostavte vlastný obraz, bez preberania starej základnej vrstvy z cache.

# Príklad: znovu zostaviť obraz, základný obraz aktívne stiahnuť nanovo
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .

# Skontrolovať verziu PHP v novom obraze pred rolloutom
docker run --rm registry.example.com/shop/web:2026-10-25 php -v

Nespoliehajte sa na tagy ako latest alebo na samotnú hlavnú verziu. V manifeste podľa možnosti odkazujte na digest nového obrazu, aby bolo jednoznačné, aký stav sa nasadzuje. Ak nasadenie prebieha cez GitOps alebo Helm, zmeňte obraz tam, aby sa stav pri ďalšom zosúladení nevrátil späť.

Rollout a kontrola

Nový rollout postupne nahradí všetky pody workloadu. Potom skontrolujte stav v bežiacich podoch. Až vtedy je záplata účinná, pretože nové súbory pomôžu iba vtedy, ak už nebežia staré procesy PHP.

# Rollout s novým obrazom (názvy ako prí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šetky pody reštartované, aktívny nový digest?
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v

Ak bol obraz pod rovnakým tagom znovu odoslaný, kubectl rollout restart spustí reštart; pody však obraz stiahnu nanovo iba vtedy, ak to imagePullPolicy predpisuje. Bezpečnejší je prechod na nový digest.

Prechodné opatrenia v clustri

Ak pre vašu verziu PHP ešte nie je dostupný opravený obraz, php.net odporúča prechodné opatrenia bez úplnej ochrany. V clustri nastavte obmedzenia pamäte cez limity zdrojov kontajnerov, ktoré sú založené na cgroups. Zodpovedá to odporúčaniu obmedziť pamäť cez kontajner alebo cgroups a nie cez RLIMIT_AS alebo RLIMIT_DATA.

; php.ini alebo pool FPM v obraze, napr. pripojený cez ConfigMap
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

S funkciou nahrávania php.net uvádza post_max_size = 32M. Pri PHP 8.5 pribúda fatal_error_backtraces=0. Po zmene konfigurácie je potrebný nový rollout. Doplnkovo obmedzujú NetworkPolicy odchádzajúce spojenia podov PHP a Ingress s ochrannými pravidlami môže útoky sťažiť. Pravidlá len podľa údajov požiadavky však podľa Cloudflare nestačia.

Postavte sa trvalo lepšie

Naplánujte pravidelné automatické opätovné zostavenia všetkých obrazov PHP, kontrolu obrazov v reťazci zostavenia a pravidlá, ktoré povoľujú iba podpísané alebo preverené obrazy. Ak kontajnery PHP bežia s používateľom bez práv root a s súborovým systémom chráneným proti zápisu, škoda úspešného útoku klesá. Upozornenia pre jednotlivé kontajnery nájdete na stránke Záplatovanie PHP v kontajneroch Docker, pre FrankenPHP na stránke Zabezpečenie FrankenPHP.

V mnohých clustroch nebežia aplikácie PHP osamote. Často existujú sidecar kontajnery pre logovanie alebo metriky, pomocné obrazy pre migrácie databáz a joby, ktoré sa spúšťajú len v noci. Aj obrazy tretích strán, napríklad pre wiki, monitorovacie rozhranie alebo ticketovací systém, môžu obsahovať PHP bez toho, aby to bolo poznať z názvu. Skontrolujte preto nielen svoje vlastné aplikácie, ale každý obraz v clustri. Pre cudzie obrazy platí: počkajte na aktualizovanú verziu od výrobcu, overte jeho údaje o obsiahnutej verzii PHP a obmedzte dostupnosť, kým nebude k dispozícii. Ak takýto systém beží iba interne, riziko sa tým znižuje, ale aktualizácia sa tým nenahrádza.

Ako konkrétne pomáha PHP SOS?

• Zaznamenáme všetky workloady s PHP, ich obrazy a digesty a skontrolujeme verziu PHP v bežiacich podoch.
• Cez službu záplatovania PHP znovu zostavíme obrazy, nasadíme ich a zdokumentujeme stav pre každý workload.
• Zabezpečíme logy pred výmenou a skontrolujeme stopy útoku.
• S bezpečnostným monitoringom a automatizovanými opätovnými zostaveniami zariadime, aby sa ďalšia záplata dostala do clustra rýchlejšie.

Časté otázky

Zdroje

• php.net: bezpečnostné hlásenia
• PHP 8 ChangeLog
• OWASP Cheat Sheets
• BSI