21 oktober 2026: PHP shutdown day?

Wat er gebeurde

Voor sommige organisaties is 21 oktober een dag om niet snel te vergeten. Er werden twee kwetsbaarheden in PHP bekendgemaakt met een hoog risico op misbruik: CVE-2026-109618 en CVE-2026-109619, samen bekend als PHP2Shell. De patch werd pas later die dag verwacht. Daarom besloten veel organisaties om services te stoppen die mogelijk kwetsbaar waren.

Container of VM?

Dezelfde kwetsbaarheden hadden niet voor alle organisaties hetzelfde risicoprofiel. Applicaties in PHP die rechtstreeks op een host draaien, liepen en lopen over het algemeen meer risico. Een kwaadwillende die daar de kwetsbaarheid misbruikt, kan veel makkelijker verder het netwerk in dan bij een applicatie in een container. Dat geldt wel alleen als de container goed is opgebouwd. Patchen blijft nodig. Een goede container beperkt alleen wat een aanvaller na misbruik kan.

Helaas schort het daar nog vaak aan. Soms lijkt het alsof iemand een poging heeft gedaan om de container op een VM te laten lijken. En vaak draaien die containers ook nog eens met verhoogde privileges, gewoon omdat ontwikkelaars dan makkelijker kunnen troubleshooten.

Wat een goede container is

Een goede container draait zonder verhoogde privileges, heeft een read-only filesystem, bevat alleen de commando's die strikt nodig zijn en bij voorkeur niet eens een shell. Daarmee doet een container precies wat de bedoeling is. Hij sluit een applicatie op met het absolute minimum aan bestanden dat nodig is om te draaien. En niet te vergeten: een goede container is gebouwd op een vertrouwd base image.

Helaas is mijn ervaring als engineer dat veel organisaties het gemak voor ontwikkelaars zwaarder laten wegen dan de noodzaak om containers zo veilig mogelijk te maken. In vacatures wordt gevraagd om CKA en/of CKAD, maar CKS (Certified Kubernetes Security Specialist) wordt zelden gevraagd. En een CKADS bestaat (helaas) nog niet.

Netwerk en infrastructuur

Behalve dat containers veilig moeten zijn, moeten ook de netwerkstromen goed in beeld zijn. Volledige zero trust bestaat niet, want uiteindelijk vertrouw je altijd een groep of persoon die een beslissing neemt. Het streven naar zero trust hoort wel bij iedere organisatie.

Zoals de AVG gegevensbescherming door ontwerp vraagt (privacy by design, artikel 25), geldt iets soortgelijks voor containers: security by design. Ze moeten vanaf het begin veilig worden gebouwd en ook het deployen moet veilig gebeuren. Inkomend en uitgaand netwerkverkeer wordt geblokkeerd, tenzij het expliciet is toegestaan.

En natuurlijk moet ook de infrastructuur waarop de containers draaien veilig zijn. Denk aan hosts met een minimaal besturingssysteem, met alleen wat nodig is om containers uit te voeren. Ook hier is een read-only filesystem wenselijk.

Organisaties die nog niet zo ver zijn, raad ik aan hier werk van te maken en deze maatregelen zo snel mogelijk door te voeren. Elk cluster in Kubernetes heeft standaard al de mogelijkheden om onveilige containers privileges af te nemen en te voorkomen dat ze als root draaien (Pod Security Admission). Die controle handhaaft alleen pas als je hem per namespace aanzet.

Als deze technische maatregelen goed zijn doorgevoerd, is het risico van misbruik bij toekomstige kwetsbaarheden een stuk kleiner. En met de komst van AI is het een kwestie van tijd voordat de volgende zich aandient.

Weten wat je draait

Maar met alleen technische maatregelen zijn we er niet. Organisaties die op 21 oktober goed inzicht hadden in hun software, hadden een groot voordeel. Zij zagen snel op welke systemen PHP draaide en konden dus sneller reageren dan organisaties zonder dat inzicht.

Net zoals de technische maatregelen hierboven niet moeilijk zijn, is ook inzicht in de gebruikte software niet moeilijk te krijgen. Er zijn diverse tools die container images en hosts scannen en alle gevonden software vastleggen als SBOM (Software Bill of Materials). Dat kan in een bestand, maar ook in een centraal systeem. Een SBOM bevat de aanwezige software inclusief versienummers.

Sla je dit centraal op, dan zie je in één keer welke systemen kwetsbaar zijn voor een bepaald lek en kun je gericht actie ondernemen. Dit inzicht is net zo waardevol als de technische maatregelen.

AI als hulp

Met de komst van AI worden kwetsbaarheden steeds sneller gevonden. Ook PHP2Shell werd gevonden door onderzoekers die met AI werkten. Op zich is dat positief. Maar AI maakt het ook steeds makkelijker om bekende kwetsbaarheden te misbruiken. Tegelijk kan AI helpen om deployments te verbeteren. Vraag Claude maar eens om deze pod veiliger te maken. Je krijgt een indrukwekkende lijst met aanbevelingen. Maar ook die moeten nog worden beoordeeld en geïmplementeerd door een deskundige.

Tools die ik gebruik

Tot slot een overzicht van tools en technieken die ik zelf gebruik om deze doelen te bereiken. Er zijn vaak alternatieven die niet per se slechter zijn.

Software ontwikkeling

• SonarQube (sonarsource.com)
• Renovate (docs.renovatebot.com)

Container security

• Chisel (ubuntu.com)
• Red Hat Universal Base Image (redhat.com)
• SUSE Linux Enterprise Base Container Images (suse.com)

Secure container deployment

• Pod Security Admission (kubernetes.io)
• Rootless containers met Podman (developers.redhat.com)
• Docker Security Cheat Sheet van OWASP (cheatsheetseries.owasp.org)
• Network Policies (kubernetes.io)

Software inventory

• Dependency-Track (dependencytrack.github.io)
• sbom-operator: catalogiseert alle images in een cluster met Syft
• SBOM in Trivy (trivy.dev)

Wie verder wil, kan aanvullende tools installeren. NeuVector kan veel, heel veel. Het leert wat normaal gedrag is voor een pod en grijpt in bij afwijkend gedrag. Het kan pods (automatisch) isoleren als er kritieke kwetsbaarheden in blijken te zitten. Ook netwerkstromen worden geleerd.

NeuVector wordt ontwikkeld door SUSE, maar wordt ook veel gebruikt op OpenShift, Mirantis Kubernetes en bijvoorbeeld Amazon ECS.

Veiligheid op 1 dus: technisch én organisatorisch.

Geschreven door Marco Verleun (Air-gapped Private Cloud Engineer bij I-share)

‍

‍

‍

‍

‍