Pe scurt: În Kubernetes, PHP se află în imaginea de container, nu în cluster. După PHP2Shell trebuie să reconstruiți fiecare imagine PHP Kubernetes cu versiune PHP remediată, să extindeți din nou toate workload-urile afectate și apoi să verificați starea în fiecare pod în execuție. O imagine de bază actualizată în registry nu schimbă singură nimic la podurile în execuție.
De ce clusterul nu se actualizează singur
Kubernetes administrează containere, dar nu se ocupă de software-ul din ele. Fiecare pod rulează cu imaginea din care a pornit, până când este înlocuit. Cine operează aplicații PHP în cluster poartă de aceea responsabilitatea pentru imagini, chiar dacă clusterul rulează ca serviciu administrat la un furnizor de cloud. Furnizorul întreține de regulă planul de control și nodurile, nu imaginile clienților.
PHP2Shell cuprinde CVE-2026-109618 și CVE-2026-109619, fiecare cu CVSS v4.0 9.2. Sunt afectate, printre altele, PHP-FPM, Apache cu mod_php și FrankenPHP, adică modurile de operare uzuale din imaginile PHP. Sunt remediate PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35.
Inventarul: ce imagine PHP Kubernetes rulează unde?
Începeți cu o listă a tuturor imaginilor din cluster. Comenzile următoare doar citesc. Numele namespace-urilor, deployment-urilor și containerelor sunt exemple.
# Toate imaginile tuturor podurilor, grupate
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'
# Digest-ul imaginii care rulează efectiv, pentru fiecare container
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'
# Versiunea PHP într-un pod în execuție
kubectl exec -n shop deploy/web -c php -- php -v
Pe lângă deployment-uri, gândiți-vă și la StatefulSet-uri, DaemonSet-uri, CronJob-uri și containere init. În clusterele mai mari ajută scannerele de imagini, care caută în imagini CVE-uri cunoscute. La pachetele distribuției din interiorul imaginii se aplică, ca peste tot: un backport poate lăsa numărul de versiune neschimbat, iar atunci contează jurnalul de modificări al pachetului.
Reconstruiți imaginile
Actualizați mai întâi imaginea de bază. Dacă folosiți imagini PHP oficiale, alegeți o variantă cu versiune PHP remediată. Reconstruiți apoi propria imagine, fără a prelua din cache vechiul strat de bază.
# Exemplu: reconstruiți imaginea, preluați activ din nou imaginea de bază
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .
# Verificați versiunea PHP din noua imagine înainte de rollout
docker run --rm registry.example.com/shop/web:2026-10-25 php -v
Nu vă bazați pe tag-uri precum latest sau pe o simplă versiune principală. Referențiați în manifest, pe cât posibil, digest-ul noii imagini, pentru a fi clar ce stare este extinsă. Dacă livrarea se face prin GitOps sau Helm, modificați imaginea acolo, pentru ca starea să nu fie resetată la următoarea sincronizare.
Rollout și control
Un rollout nou înlocuiește treptat toate podurile unui workload. Apoi verificați starea în podurile în execuție. Abia atunci patchul este eficient, deoarece fișierele noi ajută doar dacă procesele PHP vechi nu mai rulează.
# Rollout cu imagine nouă (numele ca exemplu)
kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256:<digest>
kubectl -n shop rollout status deploy/web
# Control: au fost repornite toate podurile, este activ noul digest?
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v
Dacă imaginea a fost împinsă din nou sub același tag, kubectl rollout restart declanșează o repornire; podurile descarcă însă din nou imaginea doar dacă imagePullPolicy o prevede. Mai sigură este trecerea la un digest nou.
Salvați jurnalele înainte de a înlocui podurile. Odată cu vechiul pod dispar și jurnalele sale locale. Păstrați jurnalele serverului web și ale aplicației începând cu 20.10.2026, ideal într-o platformă centrală de jurnale.
Măsuri provizorii în cluster
Dacă pentru versiunea dumneavoastră PHP nu este încă disponibilă o imagine remediată, php.net recomandă măsuri provizorii fără protecție completă. În cluster setați limitele de memorie prin limitele de resurse ale containerelor, care se bazează pe cgroups. Aceasta corespunde recomandării de a limita memoria prin container sau cgroups și nu prin RLIMIT_AS sau RLIMIT_DATA.
; php.ini sau pool FPM în imagine, de ex. integrat printr-un ConfigMap
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Cu funcție de încărcare, php.net indică post_max_size = 32M. Pe PHP 8.5 se adaugă fatal_error_backtraces=0. După modificarea configurației este necesar un nou rollout. În completare, NetworkPolicy-urile limitează conexiunile de ieșire ale podurilor PHP, iar un Ingress cu reguli de protecție poate îngreuna tentativele de atac. Reguli bazate doar pe datele cererii nu sunt însă suficiente, potrivit Cloudflare.
Pregătiți-vă mai bine pe termen lung
Planificați reconstruiri automate periodice ale tuturor imaginilor PHP, o verificare a imaginilor în lanțul de build și politici care permit doar imagini semnate sau verificate. Dacă containerele PHP rulează cu un utilizator fără drepturi de root și cu sistem de fișiere protejat la scriere, paguba unui atac reușit scade. Indicații pentru containere individuale găsiți la Actualizarea PHP în containere Docker, pentru FrankenPHP la Securizarea FrankenPHP.
În multe clustere, aplicațiile PHP nu rulează singure. Adesea există containere sidecar pentru logging sau metrici, imagini auxiliare pentru migrări de baze de date și joburi care pornesc doar noaptea. Și imaginile unor terți, de exemplu pentru un wiki, o interfață de monitorizare sau un sistem de tichete, pot conține PHP fără ca acest lucru să fie vizibil din nume. Verificați de aceea nu doar propriile aplicații, ci fiecare imagine din cluster. Pentru imaginile străine se aplică: așteptați o variantă actualizată a producătorului, verificați informațiile acestuia despre versiunea PHP inclusă și limitați accesibilitatea până când aceasta există. Dacă un astfel de sistem rulează doar intern, riscul scade, dar actualizarea nu este înlocuită.
Cum ajută PHP SOS concret?
- Inventariem toate workload-urile cu PHP, imaginile și digest-urile lor și verificăm versiunea PHP din podurile în execuție.
- Prin serviciul de patch PHP reconstruim imaginile, le extindem prin rollout și documentăm starea fiecărui workload.
- Salvăm jurnalele înainte de înlocuire și verificăm urmele unui atac.
- Prin monitorizarea de securitate și reconstruirile automate ne asigurăm că următorul patch ajunge mai repede în cluster.
Întrebări frecvente
Este suficient să actualizez imaginea de bază în registry?
Nu. Podurile în execuție folosesc în continuare imaginea cu care au pornit. Abia un rollout nou, cu imaginea reconstruită, înlocuiește podurile. Verificați apoi versiunea PHP în fiecare pod în execuție.
De ce să referențiem imaginile prin digest?
Un tag poate indica stări diferite ale imaginii, în funcție de momentul în care a fost descărcat. Un digest denumește exact o singură stare. Astfel știți sigur ce cod rulează în ce pod, iar rollout-urile devin trasabile.
Ce se întâmplă cu CronJob-urile și containerele init?
Și ele pot conține PHP și fac parte din inventar. CronJob-urile pornesc la fiecare rulare poduri noi din șablonul lor; actualizați de aceea imaginea din șablon. Containerele init rulează la pornirea fiecărui pod.
Protejează o NetworkPolicy împotriva PHP2Shell?
Nu închide vulnerabilitatea, dar poate limita paguba. Cine restricționează conexiunile de ieșire ale podurilor PHP îngreunează reîncărcarea de cod malițios și deplasările laterale în cluster.