Lühidalt: Kubernetesis asub PHP konteineri tõmmises, mitte klastris. Pärast PHP2Shelli peate iga Kubernetes PHP-tõmmise parandatud PHP versiooniga uuesti ehitama, kõik mõjutatud töökoormused uuesti välja rullima ning seejärel igas töötavas pod'is seisu kontrollima. Ajakohastatud baastõmmis registris üksi töötavaid podisid ei muuda.
Miks klaster ise ei paika
Kubernetes haldab konteinereid, kuid ei hoolitse nendes oleva tarkvara eest. Iga pod töötab tõmmisega, millest ta käivitati, kuni ta asendatakse. Kes käitab klastris PHP rakendusi, vastutab seetõttu tõmmiste eest, ka siis, kui klaster töötab hallatava teenusena pilveteenuse pakkuja juures. Pakkuja hooldab tavaliselt juhtimistasandit ja sõlmi, mitte klientide tõmmiseid.
PHP2Shell hõlmab turvauke CVE-2026-109618 ja CVE-2026-109619, kumbki hindega CVSS v4.0 9,2. Mõjutatud on muu hulgas PHP-FPM, Apache koos mod_php-ga ja FrankenPHP, see tähendab PHP tõmmiste tavalised töörežiimid. Parandatud on PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35.
Inventuur: milline Kubernetes PHP-tõmmis kus töötab?
Alustage klastri kõigi tõmmiste loendiga. Järgmised käsud ainult loevad. Nimeruumide, juurutuste ja konteinerite nimed on näited.
# 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}'
# Tegelikult töötav tõmmise digest iga konteineri kohta
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
Mõelge Deployment'ite kõrval ka StatefulSet'idele, DaemonSet'idele, CronJob'idele ja init-konteineritele. Suuremates klastrites aitavad tõmmiseskannerid, mis otsivad tõmmistest teadaolevaid CVE-sid. Tõmmises olevate distributsioonipakettide puhul kehtib nagu kõikjal: backport võib jätta versiooninumbri muutmata, siis loeb paketi muudatuslogi.
Ehitage tõmmised uuesti
Uuendage kõigepealt baastõmmis. Kui kasutate ametlikke PHP tõmmiseid, valige variant parandatud PHP versiooniga. Seejärel ehitage oma tõmmis uuesti, võtmata vana baaskihti vahemälust.
# Näide: tõmmis uuesti ehitada, baastõmmis aktiivselt uuesti tõmmata
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .
# Enne väljarullimist kontrollida PHP versiooni uues tõmmises
docker run --rm registry.example.com/shop/web:2026-10-25 php -v
Ärge lootke silditele nagu latest ega pelgalt põhiversioonile. Viidake manifestis võimaluse korral uue tõmmise digestile, et oleks üheselt selge, milline seis välja rullitakse. Kui juurutus toimub GitOpsi või Helmi kaudu, muutke tõmmis seal, et seisu ei lähtestataks järgmisel võrdlusel tagasi.
Väljarullimine ja kontroll
Uus väljarullimine asendab töökoormuse kõik podid järk-järgult. Seejärel kontrollite seisu töötavates podides. Alles siis on paik mõjus, sest uutest failidest on abi ainult siis, kui vanad PHP protsessid enam ei tööta.
# Väljarullimine uue tõmmisega (nimed on näited)
kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256:<digest>
kubectl -n shop rollout status deploy/web
# Kontroll: kas kõik podid on uuesti käivitatud ja uus digest aktiivne?
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v
Kui tõmmis lükati samale sildile uuesti, käivitab kubectl rollout restart taaskäivituse; podid tõmbavad tõmmise aga uuesti ainult siis, kui imagePullPolicy seda ette näeb. Kindlam on üleminek uuele digestile.
Kindlustage logid enne podide asendamist. Vana pod'iga kaovad ka tema kohalikud protokollid. Säilitage veebiserveri ja rakenduse logid alates 20.10.2026, parimal juhul keskses logiplatvormis.
Ajutised meetmed klastris
Kui teie PHP versiooni jaoks pole veel parandatud tõmmist saadaval, soovitab php.net ajutisi meetmeid ilma täieliku kaitseta. Klastris seadke mälupiirangud konteinerite ressursilimiitide kaudu, mis põhinevad cgroupidel. See vastab soovitusele piirata mälu konteineri või cgroupide kaudu, mitte RLIMIT_AS või RLIMIT_DATA abil.
; php.ini või FPM-pool tõmmises, nt ConfigMapi kaudu lisatud
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Üleslaadimisfunktsiooniga nimetab php.net post_max_size = 32M. PHP 8.5 puhul lisandub fatal_error_backtraces=0. Pärast seadistuse muutmist on vajalik uus väljarullimine. Lisaks piiravad NetworkPolicy'd PHP podide väljuvaid ühendusi ning kaitsereeglitega Ingress võib rünnakukatseid raskendada. Reeglitest üksnes päringuandmete põhjal Cloudflare'i hinnangul siiski ei piisa.
Püsivalt paremini üles seatud
Planeerige kõigi PHP tõmmiste regulaarsed automaatsed uuesti ehitamised, tõmmiste kontroll ehitusahelas ja eeskirjad, mis lubavad ainult allkirjastatud või kontrollitud tõmmiseid. Kui PHP konteinerid töötavad ilma root-õigusteta kasutajaga ja kirjutuskaitstud failisüsteemiga, väheneb eduka rünnaku kahju. Nõuanded üksikute konteinerite kohta leiate lehelt PHP paikamine Dockeri konteinerites, FrankenPHP kohta lehelt FrankenPHP turvamine.
Paljudes klastrites ei tööta PHP rakendused üksi. Sageli on olemas sidecar-konteinerid logimiseks või mõõdikuteks, abitõmmised andmebaasimigratsioonide jaoks ja tööd, mis käivituvad ainult öösel. Ka kolmandate osapoolte tõmmised, näiteks wiki, seirekeskkonna või piletisüsteemi jaoks, võivad sisaldada PHP-d, ilma et see nimest nähtav oleks. Kontrollige seetõttu mitte ainult oma rakendusi, vaid iga klastri tõmmist. Võõraste tõmmiste puhul kehtib: oodake tootja ajakohastatud versiooni, kontrollige tema andmeid sisalduva PHP versiooni kohta ja piirake kättesaadavust, kuni see on olemas. Kui selline süsteem töötab ainult sisemiselt, vähendab see riski, kuid ei asenda uuendust.
Kuidas PHP SOS konkreetselt aitab?
- Kaardistame kõik PHP-ga töökoormused, nende tõmmised ja digestid ning kontrollime PHP versiooni töötavates podides.
- PHP paikamisteenuse kaudu ehitame tõmmised uuesti, rullime need välja ja dokumenteerime seisu iga töökoormuse kohta.
- Kindlustame logid enne väljavahetamist ja kontrollime rünnaku jälgi.
- Turvaseire ja automatiseeritud uuesti ehitamisega hoolitseme selle eest, et järgmine paik jõuaks klastrisse kiiremini.
Korduma kippuvad küsimused
Kas piisab baastõmmise ajakohastamisest registris?
Ei. Töötavad podid kasutavad edasi tõmmist, millega nad käivitati. Alles uus väljarullimine (rollout) uuesti ehitatud tõmmisega asendab podid. Kontrollige seejärel PHP versiooni igas töötavas pod'is.
Miks viidata tõmmistele digesti kaudu?
Silt (tag) võib viidata erinevatele tõmmise seisudele, olenevalt sellest, millal see tõmmati. Digest nimetab täpselt ühe seisu. Nii teate kindlalt, milline kood millises pod'is töötab, ja väljarullimised muutuvad jälgitavaks.
Mis saab CronJob'idest ja init-konteineritest?
Needki võivad PHP-d sisaldada ja kuuluvad inventuuri. CronJob'id käivitavad igal jooksul oma malli põhjal uued podid; uuendage seetõttu tõmmis mallis. Init-konteinerid töötavad iga pod'i käivitamisel.
Kas NetworkPolicy kaitseb PHP2Shelli eest?
See ei sulge turvaauku, kuid võib kahju piirata. Kes piirab PHP podide väljuvaid ühendusi, raskendab kahjuliku koodi järelelaadimist ja külgsuunalist liikumist klastris.