Kort gezegd: In Kubernetes zit PHP in het containerimage, niet in de cluster. Na PHP2Shell moet u elk Kubernetes PHP-image met gecorrigeerde PHP-versie opnieuw bouwen, alle getroffen workloads opnieuw uitrollen en daarna in elke lopende pod de status controleren. Een bijgewerkt basisimage in het register alleen verandert niets aan lopende pods.
Waarom de cluster zelf niet patcht
Kubernetes beheert containers, maar bekommert zich niet om de software erin. Elke pod draait met het image waaruit hij is gestart, totdat hij wordt vervangen. Wie PHP-toepassingen in de cluster draait, draagt daarom de verantwoordelijkheid voor de images, ook als de cluster als beheerde dienst bij een cloudaanbieder draait. De aanbieder onderhoudt doorgaans het besturingsvlak en de nodes, niet de images van klanten.
PHP2Shell omvat CVE-2026-109618 en CVE-2026-109619, elk met CVSS v4.0 9.2. Getroffen zijn onder meer PHP-FPM, Apache met mod_php en FrankenPHP, dus de gebruikelijke uitvoeringsmodi in PHP-images. Verholpen zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35.
Inventarisatie: welk Kubernetes PHP-image draait waar?
Begin met een lijst van alle images in de cluster. De volgende opdrachten lezen alleen. Namen van namespaces, deployments en containers zijn voorbeelden.
# Alle images van alle pods, gegroepeerd
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'
# Daadwerkelijk draaiende image-digest per container
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'
# PHP-versie in een draaiende pod
kubectl exec -n shop deploy/web -c php -- php -v
Denk naast deployments ook aan StatefulSets, DaemonSets, CronJobs en init-containers. In grotere clusters helpen imagescanners die images doorzoeken op bekende CVE's. Bij distributiepakketten binnen het image geldt zoals overal: een backport kan het versienummer ongewijzigd laten, dan telt het wijzigingslogboek van het pakket.
Images opnieuw bouwen
Werk eerst het basisimage bij. Gebruikt u officiële PHP-images, kies dan een variant met gecorrigeerde PHP-versie. Bouw vervolgens uw eigen image opnieuw, zonder de oude basislaag uit de cache over te nemen.
# Voorbeeld: image opnieuw bouwen, basisimage actief opnieuw ophalen
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .
# PHP-versie in het nieuwe image controleren vóór de rollout
docker run --rm registry.example.com/shop/web:2026-10-25 php -v
Vertrouw niet op tags zoals latest of een louter hoofdversie. Verwijs in het manifest bij voorkeur naar de digest van het nieuwe image, zodat duidelijk is welke versie wordt uitgerold. Loopt de oplevering via GitOps of Helm, wijzig het image dan daar, zodat de status bij de volgende synchronisatie niet wordt teruggezet.
Rollout en controle
Een nieuwe rollout vervangt alle pods van een workload stapsgewijs. Daarna controleert u de status in de lopende pods. Pas dan is de patch effectief, want nieuwe bestanden helpen alleen als oude PHP-processen niet meer draaien.
# Rollout met nieuw image (namen als voorbeeld)
kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256:<digest>
kubectl -n shop rollout status deploy/web
# Controle: alle pods herstart, nieuwe digest actief?
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v
Is het image onder dezelfde tag opnieuw gepusht, dan start kubectl rollout restart een herstart; pods halen het image echter alleen opnieuw op als de imagePullPolicy dat voorschrijft. Veiliger is de overstap naar een nieuwe digest.
Leg logs vast voordat u pods vervangt. Met de oude pod verdwijnen ook zijn lokale logboeken. Bewaar logs van webserver en toepassing vanaf 20-10-2026, bij voorkeur in een centraal logplatform.
Overbruggingsmaatregelen in de cluster
Is voor uw PHP-versie nog geen gecorrigeerd image beschikbaar, dan adviseert php.net overbruggingsmaatregelen zonder volledige bescherming. In de cluster stelt u geheugengrenzen in via de resourcelimieten van de containers, die op cgroups berusten. Dat komt overeen met het advies het geheugen via container of cgroups te beperken en niet via RLIMIT_AS of RLIMIT_DATA.
; php.ini of FPM-pool in het image, bijv. via ConfigMap ingebonden
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Met uploadfunctie noemt php.net post_max_size = 32M. Op PHP 8.5 komt fatal_error_backtraces=0 erbij. Na wijziging van de configuratie is een nieuwe rollout nodig. Aanvullend beperken NetworkPolicies de uitgaande verbindingen van de PHP-pods, en een ingress met beschermingsregels kan aanvalspogingen bemoeilijken. Regels op basis van alleen de verzoekgegevens volstaan volgens Cloudflare echter niet.
Duurzaam beter opstellen
Plan regelmatige automatische rebuilds van alle PHP-images, een imagecontrole in de buildketen en richtlijnen die alleen ondertekende of gecontroleerde images toelaten. Draaien PHP-containers met een gebruiker zonder rootrechten en een tegen schrijven beveiligd bestandssysteem, dan neemt de schade van een geslaagde aanval af. Aanwijzingen voor afzonderlijke containers staan onder PHP in Docker-containers patchen, voor FrankenPHP onder FrankenPHP beveiligen.
In veel clusters draaien PHP-toepassingen niet alleen. Vaak zijn er sidecar-containers voor logging of metrics, hulpimages voor databasemigraties en jobs die alleen 's nachts starten. Ook images van derden, bijvoorbeeld voor een wiki, een monitoringinterface of een ticketsysteem, kunnen PHP bevatten zonder dat dat aan de naam te zien is. Controleer daarom niet alleen uw eigen toepassingen, maar elk image in de cluster. Voor vreemde images geldt: wacht op een bijgewerkte versie van de fabrikant, controleer zijn opgave over de ingesloten PHP-versie en beperk de bereikbaarheid totdat die er is. Draait zo'n systeem alleen intern, dan verlaagt dat het risico, maar het vervangt de update niet.
Hoe helpt PHP SOS concreet?
- Wij inventariseren alle workloads met PHP, hun images en digests en controleren de PHP-versie in lopende pods.
- Via de PHP-patchservice bouwen we images opnieuw, rollen we ze uit en documenteren we de status per workload.
- Wij leggen logs vast vóór de vervanging en controleren op sporen van een aanval.
- Met security monitoring en geautomatiseerde rebuilds zorgen we ervoor dat de volgende patch sneller in de cluster aankomt.
Veelgestelde vragen
Volstaat het om het basisimage in het register bij te werken?
Nee. Lopende pods blijven het image gebruiken waarmee ze zijn gestart. Pas een nieuwe rollout met het opnieuw gebouwde image vervangt de pods. Controleer daarna de PHP-versie in elke lopende pod.
Waarom images via digest refereren?
Een tag kan naar verschillende imageversies wijzen, afhankelijk van wanneer hij is opgehaald. Een digest benoemt precies één versie. Zo weet u zeker welke code in welke pod draait, en rollouts worden traceerbaar.
Hoe zit het met CronJobs en init-containers?
Ook zij kunnen PHP bevatten en horen bij de inventarisatie. CronJobs starten bij elke run nieuwe pods uit hun sjabloon; werk daarom het image in het sjabloon bij. Init-containers draaien bij het starten van elke pod.
Beschermt een NetworkPolicy tegen PHP2Shell?
Ze sluit de kwetsbaarheid niet, maar kan de schade beperken. Wie uitgaande verbindingen van PHP-pods beperkt, bemoeilijkt het nalaten van schadelijke code en zijwaartse bewegingen in de cluster.