Kort sagt: I Kubernetes sidder PHP i container-imaget, ikke i klyngen. Efter PHP2Shell skal I bygge hvert Kubernetes PHP-image med rettet PHP-version på ny, rulle alle berørte workloads ud igen og bagefter kontrollere statussen i hver kørende pod. Et opdateret basis-image i registry ændrer alene intet ved kørende pods.
Hvorfor klyngen ikke patcher sig selv
Kubernetes administrerer containere, men tager sig ikke af softwaren i dem. Hver pod kører med det image, den blev startet fra, indtil den erstattes. Den, der driver PHP-applikationer i klyngen, bærer derfor ansvaret for imagesene, også selv om klyngen kører som administreret tjeneste hos en cloududbyder. Udbyderen vedligeholder typisk kontrolplanet og noderne, ikke kundernes images.
PHP2Shell omfatter CVE-2026-109618 og CVE-2026-109619, hver med CVSS v4.0 9,2. Berørt er bl.a. PHP-FPM, Apache med mod_php og FrankenPHP, altså de sædvanlige driftsformer i PHP-images. Rettet er PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35.
Optælling: hvilket Kubernetes PHP-image kører hvor?
Begynd med en liste over alle images i klyngen. Følgende kommandoer læser kun. Navne på namespaces, deployments og containere er eksempler.
# Alle images for alle pods, grupperet
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'
# Faktisk kørende image-digest pr. container
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'
# PHP-version i en kørende pod
kubectl exec -n shop deploy/web -c php -- php -v
Tænk ved siden af deployments også på StatefulSets, DaemonSets, CronJobs og init-containere. I større klynger hjælper image-scannere, der gennemsøger images efter kendte CVE'er. Ved distributionspakker inde i imaget gælder som alle andre steder: En backport kan lade versionsnummeret stå uændret, så tæller pakkens ændringslog.
Byg images på ny
Opdatér først basis-imaget. Bruger I officielle PHP-images, så vælg en variant med rettet PHP-version. Byg derefter jeres eget image på ny uden at overtage det gamle basislag fra cachen.
# Eksempel: byg image på ny, hent basis-imaget aktivt på ny
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .
# Kontrollér PHP-versionen i det nye image før rollout
docker run --rm registry.example.com/shop/web:2026-10-25 php -v
Stol ikke på tags som latest eller en blot hovedversion. Refererer i manifestet helst til det nye image's digest, så det er entydigt, hvilken status der rulles ud. Kører udrulningen via GitOps eller Helm, så ændr imaget dér, så statussen ikke nulstilles ved næste afstemning.
Rollout og kontrol
Et nyt rollout erstatter alle pods i en workload trinvis. Bagefter kontrollerer I statussen i de kørende pods. Først da er patchen virksom, for nye filer hjælper kun, hvis gamle PHP-processer ikke længere kører.
# Rollout med nyt image (navne som eksempel)
kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256:<digest>
kubectl -n shop rollout status deploy/web
# Kontrol: alle pods genstartet, ny digest aktiv?
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v
Er imaget pushet på ny under samme tag, udløser kubectl rollout restart en genstart; pods henter dog kun imaget på ny, hvis imagePullPolicy foreskriver det. Sikrere er skiftet til en ny digest.
Sikr logs, før I erstatter pods. Med den gamle pod forsvinder også dens lokale protokoller. Gem webserver- og applikationslogs fra og med 20.10.2026, helst i en central logplatform.
Midlertidige foranstaltninger i klyngen
Er der til jeres PHP-version endnu intet rettet image tilgængeligt, anbefaler php.net midlertidige foranstaltninger uden fuldstændig beskyttelse. I klyngen sætter I hukommelsesgrænser via containernes ressourcelimits, der bygger på cgroups. Det svarer til anbefalingen om at begrænse hukommelsen via containere eller cgroups og ikke via RLIMIT_AS eller RLIMIT_DATA.
; php.ini eller FPM-pool i imaget, f.eks. indbundet via ConfigMap
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Med upload-funktion angiver php.net post_max_size = 32M. På PHP 8.5 kommer fatal_error_backtraces=0 til. Efter ændring af konfigurationen er et nyt rollout nødvendigt. Som supplement begrænser NetworkPolicies udgående forbindelser fra PHP-podsene, og en ingress med beskyttelsesregler kan besværliggøre angrebsforsøg. Regler alene på grundlag af forespørgselsdata er dog ifølge Cloudflare ikke tilstrækkelige.
Stil jer varigt bedre
Planlæg regelmæssige automatiske rebuilds af alle PHP-images, en image-kontrol i build-kæden og retningslinjer, der kun tillader signerede eller kontrollerede images. Kører PHP-containere med bruger uden root-rettigheder og skrivebeskyttet filsystem, falder skaden ved et vellykket angreb. Henvisninger for enkelte containere står under Patch PHP i Docker-containere, for FrankenPHP under Sådan sikrer I FrankenPHP.
I mange klynger kører PHP-applikationer ikke alene. Ofte findes der sidecar-containere til logning eller målinger, hjælpe-images til databasemigreringer og jobs, der kun starter om natten. Også images fra tredjepartsleverandører, f.eks. til en wiki, en overvågningsflade eller et ticketsystem, kan indeholde PHP, uden at det kan ses af navnet. Kontrollér derfor ikke kun jeres egne applikationer, men hvert image i klyngen. For fremmede images gælder: Vent på en opdateret udgave fra producenten, kontrollér dennes oplysninger om den indeholdte PHP-version, og begræns tilgængeligheden, indtil den foreligger. Kører et sådant system kun internt, sænker det risikoen, men erstatter ikke opdateringen.
Hvordan hjælper PHP SOS konkret?
- Vi opgør alle workloads med PHP, deres images og digests og kontrollerer PHP-versionen i kørende pods.
- Via PHP-patch-servicen bygger vi images på ny, ruller dem ud og dokumenterer statussen pr. workload.
- Vi sikrer logs før udskiftningen og undersøger for spor af et angreb.
- Med sikkerhedsovervågning og automatiserede rebuilds sørger vi for, at den næste patch kommer hurtigere ud i klyngen.
Ofte stillede spørgsmål
Er det nok at opdatere basis-imaget i registry?
Nej. Kørende pods bruger fortsat det image, de blev startet med. Først et nyt rollout med det nybyggede image erstatter podsene. Kontrollér bagefter PHP-versionen i hver kørende pod.
Hvorfor referere til images via digest?
Et tag kan pege på forskellige image-statusser, afhængigt af hvornår det blev hentet. En digest betegner nøjagtigt én status. Dermed ved I med sikkerhed, hvilken kode der kører i hvilken pod, og rollouts bliver sporbare.
Hvad med CronJobs og init-containere?
Også de kan indeholde PHP og hører med til optællingen. CronJobs starter ved hver kørsel nye pods fra deres skabelon; opdatér derfor imaget i skabelonen. Init-containere kører ved starten af hver pod.
Beskytter en NetworkPolicy mod PHP2Shell?
Den lukker ikke sårbarheden, men kan begrænse skaden. Den, der begrænser udgående forbindelser fra PHP-pods, besværliggør nedlastning af skadelig kode og sideværts bevægelser i klyngen.