PHP2Shell: wat CISO's nu moeten regelen na het PHP-lek

Op 21 oktober 2026 bracht het PHP-project PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uit tegen twee kritieke kwetsbaarheden, CVE-2026-109618 en CVE-2026-109619, die ongeauthenticeerde remote code execution mogelijk maken. Inmiddels worden ze actief misbruikt, en op 23 oktober kwam er een derde lek bij. Voor een CISO is de patch het makkelijke deel. Het werk zit in drie vragen: waar draait PHP overal (ook bij leveranciers), wie voert de updates uit, en wie kan achteraf aantonen dat het gebeurd is?

Wat is er precies aan de hand met PHP2Shell?

Het gaat om twee kwetsbaarheden die allebei een CVSS-score van 9.2 kregen, zo staat in het advies van CERT-EU, het cybersecurityteam van de EU-instellingen:

• CVE-2026-109618 is een geheugenfout bij het afhandelen van een geheugentekort. Wordt een request onderbroken tijdens het verwerken van een formulier-upload, dan kan de opruimroutine niet-geïnitialiseerd geheugen vrijgeven.
• CVE-2026-109619 draait om achtergebleven globale state. Gegevens die een fatale fout overleven, kunnen door een volgend request op dezelfde worker worden gebruikt.

Beide leiden tot remote code execution zonder inloggen. Het PHP-project heeft een exploit gedemonstreerd waarbij één ongeauthenticeerd verzoek de aanval start voordat er een regel applicatiecode draait. WAF-regels en applicatielogica helpen je in dat scenario weinig.

Het NCSC meldde op 21 oktober in zijn waarschuwing via Rijksoverheid.nl dat in ieder geval alle PHP-versies vanaf versie 5 kwetsbaar zijn, dat er publieke proof-of-concept-code bestaat en dat een eenvoudig POST-verzoek volstaat. Uit voorzorg ging zelfs ncsc.nl tijdelijk offline. Actief misbruik had het NCSC toen nog niet gezien. Dat is veranderd: het Canadese Cyber Centre meldt dat de Amerikaanse CISA beide CVE's op 26 oktober aan zijn lijst van actief misbruikte kwetsbaarheden toevoegde.

Op 23 oktober maakte het PHP-project daarbovenop CVE-2026-115560 bekend, een derde lek dat ook tot remote code execution kan leiden en dat de updates van 21 oktober niet dichten. Tot de volgende reguliere release is de aanbevolen maatregel session.upload_progress.enabled=0 in php.ini of de FPM-pool, met een herstart van alle workers.

Waarom dit meer is dan een gewone patchronde

PHP zit zelden alleen in de webservers van je eigen team. Het draait in contentmanagementsystemen, klantportalen, intranetten, monitoringtools, appliances en SaaS-diensten van derden. Een aantal distributies en LTS-leveranciers levert eigen, teruggezette fixes. Een versienummer zegt dus niet alles: een distributiepakket kan een ouder upstream-nummer houden en toch gepatcht zijn.

PHP 8.1 en ouder krijgen geen updates meer van het PHP-project. Voor 7.4, 8.0 en 8.1 zijn alleen minimale broncode-patches gepubliceerd, voor wie zelf compileert of geen LTS-leverancier heeft. En de beschikbare mitigaties, zoals een vaste memory_limit, een lage post_max_size of het uitzetten van upload progress, verkleinen de blootstelling maar maken een installatie niet veilig. Alleen de update lost het op. Staat er "we hebben een workaround" in een statusrapport, vraag dan door.

Dan de regelgeving. Sinds 15 augustus 2026 geldt de Cyberbeveiligingswet, de Nederlandse invulling van NIS2. Organisaties die eronder vallen, moeten passende en evenredige maatregelen nemen voor de beveiliging van hun netwerk- en informatiesystemen en incidenten snel melden bij hun CSIRT en toezichthouder. Het bestuur keurt die maatregelen goed en houdt toezicht op de uitvoering. Een kritiek, breed gecommuniceerd en actief misbruikt lek waarvoor een patch bestaat, is precies het soort situatie waarvan een toezichthouder later wil zien hoe je hebt gehandeld.

De capaciteitsvraag: wie doet dit?

Mijn inschatting: bij een lek als dit zit de bottleneck eerder bij mensen dan bij techniek. Het vulnerability management-team heeft al een volle lijst, de Linux- en middlewarebeheerders hebben een backlog, en iemand moet tientallen leveranciers tegelijk bevragen. Ondertussen moet er per systeem een besluit komen of het offline gaat zolang patchen niet lukt.

Deze profielen heb je de komende weken nodig:

• Vulnerability management specialist: brengt alle PHP-instanties in kaart, ook in containerimages en appliances, en bewaakt de voortgang tot de laatste host is bijgewerkt.
• Linux- en middleware engineer met securityfocus: voert de updates uit, herstart alle workers (een vergeten FPM-pool is een open deur) en controleert dat applicaties de configuratie niet overschrijven.
• Third-party risk manager: stuurt gerichte vragen naar leveranciers en SaaS-partijen, legt antwoorden en patchdata vast en escaleert waar het stil blijft.
• DFIR- of threat hunting-specialist: zoekt op systemen die langer kwetsbaar waren naar sporen van misbruik, zodat je bij een melding feiten hebt.
• GRC-specialist: legt besluiten, risicoafwegingen en tijdlijnen zo vast dat ze standhouden bij een audit of een vraag van de toezichthouder.

Die rollen werf je niet in een week vast. Hier werkt interim het best: ervaren mensen die binnen een paar dagen meedraaien, een afgebakend doel hebben en daarna weer vertrekken. Welk talent je in het algemeen nodig hebt voor de Cyberbeveiligingswet, lees je in dit stuk over NIS2-compliance.

Wat moet je nu doen

1. Maak een lijst van alle internetgerichte systemen met PHP, inclusief appliances, containerimages en applicaties van derden.
2. Upgrade naar PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35, of installeer de update van je distributie of LTS-leverancier. Herstart daarna alle workers.
3. Zet session.upload_progress.enabled=0 tegen CVE-2026-115560 tot de volgende PHP-release er is, en plan die release alvast in.
4. Neem per systeem dat niet direct gepatcht kan worden een besluit: offline halen of afschermen van het publieke internet. Leg dat vast, met naam en datum.
5. Laat je DFIR-capaciteit logs nalopen op onverwachte processen, bestanden, accounts en uitgaande verbindingen. Het lek wordt misbruikt, dus ga niet uit van een schone omgeving.
6. Vraag leveranciers schriftelijk welke PHP-versie ze draaien, wanneer ze patchen en hoe ze dat aantonen. Geen antwoord is ook een antwoord voor je risicoregister.
7. Zet de migratie van systemen op PHP 8.1 of ouder op de roadmap.
8. Geef het bestuur een korte update met status, restrisico en besluiten.

Kom je capaciteit tekort, dan zoeken we interim-specialisten in vulnerability management en DFIR. Moet er iemand de lijnen uitzetten, kijk dan naar een interim CISO. Wat de Cyberbeveiligingswet verder van je vraagt, staat op onze NIS2-pagina. Liever direct sparren over wie je nodig hebt? Bel of mail me.