Trumpai: Kubernetes PHP slypi konteinerio atvaizde (image), o ne klasteryje. Po PHP2Shell kiekvieną Kubernetes PHP image turite iš naujo sukurti su ištaisyta PHP versija, iš naujo išvynioti (rollout) visus paveiktus workload ir po to patikrinti būseną kiekviename veikiančiame pod. Vien atnaujintas bazinis image registre veikiančių pod nepakeičia.
Kodėl pats klasteris nepataiso
Kubernetes valdo konteinerius, bet nesirūpina juose esančia programine įranga. Kiekvienas pod veikia su image, iš kurio buvo paleistas, kol bus pakeistas. Kas klasteryje eksploatuoja PHP programas, todėl atsako už image, net jei klasteris veikia kaip valdoma paslauga pas debesijos teikėją. Teikėjas paprastai prižiūri valdymo plokštumą ir mazgus, o ne klientų image.
PHP2Shell apima CVE-2026-109618 ir CVE-2026-109619, kiekvienas su CVSS v4.0 9,2. Paveikti, be kita ko, PHP-FPM, Apache su mod_php ir FrankenPHP, t. y. įprasti PHP image veikimo režimai. Ištaisyti PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35.
Esamos būklės surašymas: kuris Kubernetes PHP image kur veikia?
Pradėkite nuo visų klasterio image sąrašo. Toliau pateiktos komandos tik skaito. Vardų erdvių, deployment ir konteinerių pavadinimai yra pavyzdžiai.
# Visi visų pod image, sugrupuoti
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'
# Tikrasis veikiantis image digest kiekvienam konteineriui
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'
# PHP versija veikiančiame pod
kubectl exec -n shop deploy/web -c php -- php -v
Greta Deployment pagalvokite ir apie StatefulSet, DaemonSet, CronJob bei init konteinerius. Didesniuose klasteriuose padeda image skaitytuvai, kurie ieško žinomų CVE image viduje. Distribucijų paketų image viduje galioja kaip visur: backport gali palikti versijos numerį nepakeistą, tuomet lemia paketo pakeitimų žurnalas.
Iš naujo sukurkite image
Pirmiausia atnaujinkite bazinį image. Jei naudojate oficialius PHP image, pasirinkite variantą su ištaisyta PHP versija. Tada iš naujo sukurkite savo image, neperimdami senojo bazinio sluoksnio iš talpyklos.
# Pavyzdys: iš naujo sukurti image, aktyviai iš naujo atsisiųsti bazinį image
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .
# Prieš rollout patikrinkite PHP versiją naujame image
docker run --rm registry.example.com/shop/web:2026-10-25 php -v
Nesiremkite žymėmis, pavyzdžiui, latest, ar vien pagrindine versija. Manifeste kuo labiau nurodykite naujojo image digest, kad būtų aišku, kokia būsena išvyniojama. Jei diegimas vyksta per GitOps ar Helm, image keiskite ten, kad kito suderinimo metu būsena nebūtų atstatyta.
Rollout ir kontrolė
Naujas rollout palaipsniui pakeičia visus workload pod. Po to patikrinkite būseną veikiančiuose pod. Tik tada pataisa veikia, nes nauji failai padeda tik tada, kai seni PHP procesai nebeveikia.
# Rollout su nauju image (pavadinimai kaip pavyzdys)
kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256:<digest>
kubectl -n shop rollout status deploy/web
# Kontrolė: ar visi pod paleisti iš naujo, ar aktyvus naujas digest?
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v
Jei image po ta pačia žyme buvo išsiųstas iš naujo, kubectl rollout restart paleidžia pod iš naujo; tačiau pod image atsisiunčia iš naujo tik jei tai numato imagePullPolicy. Saugiau pereiti prie naujo digest.
Prieš keisdami pod išsaugokite žurnalus. Kartu su senuoju pod dingsta ir jo vietiniai protokolai. Išsaugokite žiniatinklio serverio ir programos žurnalus nuo 2026-10-20, geriausia centralizuotoje žurnalų platformoje.
Pereinamosios priemonės klasteryje
Jei jūsų PHP versijai dar nėra ištaisyto image, php.net rekomenduoja pereinamąsias priemones be visiškos apsaugos. Klasteryje atminties ribas nustatykite per konteinerių išteklių limitus, kurie remiasi cgroups. Tai atitinka rekomendaciją atmintį riboti per konteinerį ar cgroups, o ne per RLIMIT_AS ar RLIMIT_DATA.
; php.ini arba FPM baseinas image viduje, pvz., prijungtas per ConfigMap
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Su įkėlimo funkcija php.net nurodo post_max_size = 32M. PHP 8.5 papildomai nustatoma fatal_error_backtraces=0. Pakeitus konfigūraciją reikalingas naujas rollout. Papildomai NetworkPolicy apriboja PHP pod išeinančius ryšius, o Ingress su apsaugos taisyklėmis gali apsunkinti atakų bandymus. Tačiau vien taisyklių pagal užklausos duomenis, pasak Cloudflare, nepakanka.
Nuolat geriau pasiruoškite
Suplanuokite reguliarų automatinį visų PHP image perkūrimą, image patikrą kūrimo grandinėje ir taisykles, leidžiančias tik pasirašytus ar patikrintus image. Jei PHP konteineriai veikia su naudotoju be root teisių ir tik skaitomos failų sistemos, sėkmingos atakos žala mažėja. Nurodymus atskiriems konteineriams rasite puslapyje PHP pataisymas Docker konteineriuose, o FrankenPHP puslapyje FrankenPHP apsauga.
Daugelyje klasterių PHP programos veikia ne vienos. Dažnai yra sidecar konteinerių žurnalams ar metrikoms, pagalbinių image duomenų bazės migracijoms ir užduočių, kurios startuoja tik naktį. Ir trečiųjų šalių image, pavyzdžiui, wiki, stebėsenos sąsajai ar užklausų sistemai, gali turėti PHP, nors pagal pavadinimą to neatpažinsite. Todėl tikrinkite ne tik savo programas, bet ir kiekvieną klasterio image. Svetimiems image galioja: palaukite gamintojo atnaujinto varianto, patikrinkite jo duomenis apie įtrauktą PHP versiją ir apribokite pasiekiamumą, kol tokio varianto nėra. Jei tokia sistema veikia tik viduje, tai mažina riziką, bet atnaujinimo nepakeičia.
Kaip PHP SOS padeda konkrečiai?
- Surašome visus workload su PHP, jų image ir digest ir tikriname PHP versiją veikiančiuose pod.
- Per PHP pataisų paslaugą iš naujo sukuriame image, juos išvyniojame ir dokumentuojame kiekvieno workload būseną.
- Prieš pakeitimą išsaugome žurnalus ir tikriname dėl atakos pėdsakų.
- Su saugumo stebėsena ir automatizuotais perkūrimais pasirūpiname, kad kita pataisa į klasterį pasiektų greičiau.
Dažni klausimai
Ar pakanka registre atnaujinti bazinį image?
Ne. Veikiantys pod ir toliau naudoja image, su kuriuo buvo paleisti. Pod pakeičia tik naujas rollout su naujai sukurtu image. Po to patikrinkite PHP versiją kiekviename veikiančiame pod.
Kodėl image nurodyti per digest?
Žymė gali rodyti į skirtingas image būsenas, priklausomai nuo to, kada buvo atsisiųsta. Digest nurodo lygiai vieną būseną. Taip tiksliai žinote, kuris kodas kuriame pod veikia, o rollout tampa atsekami.
Kaip su CronJob ir init konteineriais?
Ir juose gali būti PHP, todėl jie įeina į esamos būklės surašymą. CronJob kiekvieno paleidimo metu paleidžia naujus pod iš savo šablono; todėl atnaujinkite image šablone. Init konteineriai veikia kiekvieno pod paleidimo metu.
Ar NetworkPolicy apsaugo nuo PHP2Shell?
Ji pažeidžiamumo neuždaro, bet gali apriboti žalą. Kas apriboja išeinančius PHP pod ryšius, apsunkina kenkėjiško kodo atsisiuntimą ir judėjimą į šonus klasteryje.