Fil-qosor: F'Kubernetes PHP jinsab fl-image tal-kontenitur, mhux fil-cluster. Wara PHP2Shell għandkom tibnu mill-ġdid kull image ta' PHP f'Kubernetes b'verżjoni ta' PHP irranġata, terġgħu trollaw il-workloads affettwati kollha u wara tivverifikaw l-istat f'kull pod li jaħdem. Image bażi aġġornata fir-registry waħdu ma jibdel xejn fil-pods li jaħdmu.
Għaliex il-cluster innifsu ma jippatchjax
Kubernetes jamministra kontenituri, imma ma jieħu ħsieb is-softwer ġewwa fihom. Kull pod jaħdem bl-image li minnha beda sakemm jiġi sostitwit. Min iħaddem applikazzjonijiet ta' PHP fil-cluster, għalhekk, jerfa' r-responsabbiltà għall-images, anke jekk il-cluster jaħdem bħala servizz amministrat għand fornitur tal-cloud. Il-fornitur tipikament jikkura l-pjan tal-kontroll u n-nodi, mhux l-images tal-klijenti.
PHP2Shell jinkludi CVE-2026-109618 u CVE-2026-109619, kull waħda b'CVSS v4.0 9,2. Huma affettwati, fost l-oħrajn, PHP-FPM, Apache b'mod_php u FrankenPHP, jiġifieri l-modalitajiet tat-tħaddim tas-soltu fl-images ta' PHP. Irranġati huma PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35.
Inventarju: liema image ta' PHP f'Kubernetes taħdem fejn?
Ibdew b'lista tal-images kollha fil-cluster. Il-kmandi li ġejjin jaqraw biss. L-ismijiet tan-namespaces, tad-deployments u tal-kontenituri huma eżempji.
# Alle Images aller Pods, gruppiert
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'
# Tatsächlich laufender Image-Digest je Container
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'
# PHP-Version in einem laufenden Pod
kubectl exec -n shop deploy/web -c php -- php -v
Ftakru, minbarra d-deployments, ukoll fl-StatefulSets, fid-DaemonSets, fis-CronJobs u fl-init containers. F'clusters akbar jgħinu skaners tal-images li jfittxu fl-images għal CVEs magħrufa. Fil-każ ta' pakketti tad-distribuzzjoni ġewwa l-image japplika bħal kullimkien: backport jista' jħalli n-numru tal-verżjoni bla bidla, u mbagħad jgħodd il-changelog tal-pakkett.
Nibnu mill-ġdid l-images
L-ewwel aġġornaw l-image bażi. Jekk tużaw images uffiċjali ta' PHP, agħżlu varjant b'verżjoni ta' PHP irranġata. Wara ibnu mill-ġdid l-image proprja tagħkom, mingħajr ma tieħdu mill-cache is-saff bażi l-qadim.
# Beispiel: Image neu bauen, Basis-Image aktiv neu ziehen
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .
# PHP-Version im neuen Image vor dem Rollout prüfen
docker run --rm registry.example.com/shop/web:2026-10-25 php -v
Tistrieħux fuq tags bħal latest jew sempliċi verżjoni prinċipali. Fil-manifest irreferu, jekk possibbli, għad-digest tal-image l-ġdida, biex ikun ċar liema stat jiġi rrollat. Jekk id-distribuzzjoni ssir permezz ta' GitOps jew Helm, biddlu l-image hemm, biex l-istat ma jerġax jiġi reset fil-konfront li jmiss.
Rollout u kontroll
Rollout ġdid jissostitwixxi l-pods kollha ta' workload gradwalment. Wara tivverifikaw l-istat fil-pods li jaħdmu. Biss imbagħad il-patch huwa effettiv, għax fajls ġodda jgħinu biss jekk il-proċessi qodma ta' PHP ma jibqgħux jaħdmu.
# Rollout mit neuem Image (Namen als Beispiel)
kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256:<digest>
kubectl -n shop rollout status deploy/web
# Kontrolle: alle Pods neu gestartet, neuer Digest aktiv?
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v
Jekk l-image ġiet imbuttata mill-ġdid bl-istess tag, kubectl rollout restart iqanqal restart; il-pods, madankollu, jniżżlu l-image mill-ġdid biss jekk l-imagePullPolicy jipprevedi dan. Is-sigur huwa li tgħaddu għal digest ġdid.
Issalvaw il-logs qabel ma tissostitwixxu l-pods. Mal-pod il-qadim jisparixxu wkoll il-protokolli lokali tiegħu. Żommu l-logs tas-server tal-web u tal-applikazzjoni mill-20/10/2026 'il quddiem, idealment f'pjattaforma ċentrali tal-logs.
Miżuri temporanji fil-cluster
Jekk għal verżjoni tagħkom ta' PHP għad m'hemm l-ebda image irranġata disponibbli, php.net jirrakkomanda miżuri temporanji mingħajr protezzjoni sħiħa. Fil-cluster tissettjaw limiti tal-memorja permezz tal-limiti tar-riżorsi tal-kontenituri, li jistrieħu fuq is-cgroups. Dan jikkorrispondi għar-rakkomandazzjoni li l-memorja tiġi llimitata permezz tal-kontenituri jew tas-cgroups u mhux permezz ta' RLIMIT_AS jew RLIMIT_DATA.
; php.ini oder FPM-Pool im Image, z. B. per ConfigMap eingebunden
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Meta jkun hemm funzjoni ta' upload, php.net jissuġġerixxi post_max_size = 32M. Fuq PHP 8.5 jiżdied fatal_error_backtraces=0. Wara l-bidla tal-konfigurazzjoni jkun meħtieġ rollout ġdid. Barra minn hekk, in-NetworkPolicies jillimitaw il-konnessjonijiet ħerġin tal-pods ta' PHP, u Ingress b'regoli ta' protezzjoni jista' jagħmilha aktar diffiċli għal tentattivi ta' attakk. Regoli bbażati fuq id-data tat-talba waħedha, skont Cloudflare, madankollu mhumiex biżżejjed.
Nipposizzjonaw ruħna aħjar fit-tul
Ippjanaw rebuilds awtomatiċi regolari tal-images kollha ta' PHP, verifika tal-images fil-katina tal-bini u linji gwida li jippermettu biss images iffirmati jew ivverifikati. Jekk il-kontenituri ta' PHP jaħdmu b'utent mingħajr drittijiet ta' root u b'sistema tal-fajls protetta mill-kitba, id-dannu ta' attakk b'suċċess jonqos. Noti għal kontenituri individwali jinsabu f'Patching ta' PHP fil-kontenituri Docker, għal FrankenPHP f'Kif tassiguraw FrankenPHP.
F'ħafna clusters l-applikazzjonijiet ta' PHP ma jaħdmux waħedhom. Spiss hemm sidecar containers għal-logging jew metriċi, images ta' għajnuna għal migrazzjonijiet tad-database u jobs li jibdew biss bil-lejl. Anke images ta' terzi, pereżempju għal wiki, interface ta' monitoraġġ jew sistema ta' tickets, jistgħu jinkludu PHP mingħajr ma dan jidher mill-isem. Għalhekk iċċekkjaw mhux biss l-applikazzjonijiet proprji tagħkom, imma kull image fil-cluster. Għal images barranin japplika: stennew verżjoni aġġornata tal-manifattur, iċċekkjaw l-indikazzjonijiet tiegħu dwar il-verżjoni ta' PHP inkluża u illimitaw l-aċċessibbiltà sakemm din tkun disponibbli. Jekk sistema bħal din taħdem biss b'mod intern, dan inaqqas ir-riskju, imma ma jissostitwixxix l-aġġornament.
Kif tgħin PHP SOS b'mod konkret?
- Niġbru l-workloads kollha b'PHP, l-images u d-digests tagħhom u niċċekkjaw il-verżjoni ta' PHP fil-pods li jaħdmu.
- Permezz tas-servizz ta' patch ta' PHP nibnu mill-ġdid l-images, nirrollawhom u niddokumentaw l-istat għal kull workload.
- Nissalvaw il-logs qabel is-sostituzzjoni u niċċekkjaw għal traċċi ta' attakk.
- Bil-monitoraġġ tas-sigurtà u rebuilds awtomatizzati niżguraw li l-patch li jmiss jasal aktar malajr fil-cluster.
Mistoqsijiet frekwenti
Huwa biżżejjed li naġġorna l-image bażi fir-registry?
Le. Il-pods li jaħdmu jkomplu juzaw l-image li bih bdew. Biss rollout ġdid bl-image mibnija mill-ġdid jissostitwixxi l-pods. Wara, iċċekkjaw il-verżjoni ta' PHP f'kull pod li jaħdem.
Għaliex nirreferu għall-images permezz tad-digest?
Tag jista' jindika stati differenti tal-image, skont meta ġie mniżżel. Digest jiddenomina eżattament stat wieħed. B'hekk tafu bi ċertezza liema kodiċi jaħdem f'liema pod, u r-rollouts isiru traċċabbli.
U l-CronJobs u l-init containers?
Anke dawn jistgħu jinkludu PHP u jagħmlu parti mill-inventarju. Is-CronJobs ma' kull tħaddim jibdew pods ġodda mit-template tagħhom; għalhekk aġġornaw l-image fit-template. L-init containers jaħdmu mal-bidu ta' kull pod.
NetworkPolicy tipproteġi minn PHP2Shell?
Ma tagħlaqx il-vulnerabbiltà, imma tista' tillimita d-dannu. Min jillimita l-konnessjonijiet ħerġin tal-pods ta' PHP jagħmilha aktar diffiċli li jitniżżel kodiċi malizzjuż u li jkun hemm moviment lateral fil-cluster.