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

Op 21 oktober 2026 bracht het PHP-securityteam PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uit om twee kritieke kwetsbaarheden te dichten, CVE-2026-109618 en CVE-2026-109619, die ongeauthenticeerde remote code execution mogelijk maken. Het NCSC adviseert elk internetgericht PHP-systeem als kwetsbaar te beschouwen tot het gepatcht is, en ging zelf zo ver dat het ncsc.nl tijdelijk offline haalde. Voor CISO's is de patch zelf het makkelijke deel. Het echte werk zit in drie vragen: waar draait PHP overal (ook bij leveranciers), wie voert de updates deze week uit, en wie bewijst achteraf dat het gebeurd is.

Wat is er precies aan de hand met PHP2Shell?

Volgens de officiële securitymelding van het PHP-project gaat het om twee kwetsbaarheden die allebei een CVSS v4.0-score van 9.2 hebben gekregen:

• CVE-2026-109618: remote code execution via geheugenfouten bij out-of-memory. De afhandeling van een geheugentekort kan PHP onderbreken terwijl interne requestdata nog maar half is opgebouwd, waarna de opruimroutine die ongeldige data als geldig behandelt.
• CVE-2026-109619: remote code execution via achtergebleven globale state. Interne gegevens van een request kunnen blijven bestaan nadat het onderliggende geheugen is vrijgegeven, waarna een volgend request op dezelfde worker die verouderde gegevens gebruikt.

Het PHP-project noemt alle PHP-installaties die webverzoeken afhandelen als risicogroep: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het hoogste risico ligt bij mod_php, waar een aangetoonde exploit bestaat waarbij een ongeauthenticeerd verzoek de aanval start voordat er ook maar één regel applicatiecode draait. Uw WAF-regels of applicatielogica bieden in dat scenario dus weinig houvast.

Het NCSC meldde op 21 oktober in zijn waarschuwing via Rijksoverheid.nl dat in ieder geval alle PHP-versies vanaf versie 5 als kwetsbaar worden beschouwd, dat er publieke proof-of-concept-code bestaat en dat een eenvoudig POST-verzoek volstaat om de kwetsbaarheden te misbruiken. Actief misbruik had het NCSC op dat moment nog niet waargenomen. Dat is geen reden tot geruststelling: het is een tijdvenster dat u moet benutten.

Waarom dit meer is dan een gewone patchronde

PHP zit zelden alleen in de webservers die uw eigen team beheert. Het draait in contentmanagementsystemen, klantportalen, intranetten, monitoringtools, appliances en SaaS-diensten van derden. Het NCSC wijst er in zijn alert op dat veel gebruikers afhankelijk zijn van hun softwareleverancier voor een bijgewerkte PHP-versie, en dat Linux-distributies en LTS-leveranciers eigen updates leveren. Een versienummer zegt dus niet alles: een distributiepakket kan een ouder upstream-nummer houden en toch gepatcht zijn, of andersom.

Daarbij komen twee complicaties. Ten eerste krijgen PHP 8.1 en ouder geen reguliere updates meer van het PHP-project; voor 7.4, 8.0 en 8.1 zijn alleen minimale broncode-patches beschikbaar. Ten tweede noemt het PHP-project de beschikbare mitigaties nadrukkelijk onvolledig: instellingen als session.upload_progress.enabled=0 of aanpassingen aan memory_limit en post_max_size blokkeren alleen specifieke aanvalspaden. Alleen de update lost het probleem op. Wie dus "we hebben een workaround" in een statusrapport leest, moet doorvragen.

En er is een regelgevingslaag. Sinds 15 augustus 2026 geldt de Cyberbeveiligingswet, de Nederlandse invulling van NIS2. Organisaties die eronder vallen hebben een zorgplicht om risico's voor hun netwerk- en informatiesystemen te beheersen en een meldplicht voor significante incidenten. Het bestuur is eindverantwoordelijk voor het beheersen van cyberrisico's. Een kritieke, breed gecommuniceerde kwetsbaarheid waarvoor een patch beschikbaar is, is precies het soort situatie waarin een toezichthouder later wil zien hoe u heeft gehandeld.

De capaciteitsvraag: wie doet dit deze week?

Vanuit onze positie als cybersecurity-recruiter zien we bij dit soort gebeurtenissen steeds hetzelfde patroon. Niet de techniek is de bottleneck, maar de mensen. Het vulnerability management-team draait al op volle toeren, de Linux- en middlewarebeheerders hebben een backlog, en de leveranciersmanager moet tientallen partijen tegelijk bevragen. Tegelijk moet iemand de risicoafweging maken welke systemen offline gaan, zoals het NCSC adviseert waar patchen niet direct kan.

De profielen die in de komende weken het verschil maken:

• Vulnerability management specialist: brengt alle PHP-instanties in kaart, ook in containerimages en appliances, en bewaakt de voortgang per systeem 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 configuratie niet door applicaties wordt overschreven.
• 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: controleert op systemen die langer kwetsbaar waren of er sporen van misbruik zijn, zodat u bij een eventuele melding feiten heeft in plaats van aannames.
• GRC-specialist: legt besluiten, risicoafwegingen en tijdlijnen zo vast dat ze standhouden bij een audit of een vraag van de toezichthouder.

Dit zijn geen rollen die u in een week permanent werft. Hier is interim-capaciteit op zijn sterkst: ervaren professionals die binnen dagen meedraaien, een afgebakend doel hebben en na afronding weer vertrekken. Lees ook onze eerdere analyse over welk talent je nodig hebt om NIS2-compliance aan te tonen; PHP2Shell is daar een praktijktest van.

Wat moet je nu doen

1. Inventariseer vandaag. Maak een lijst van alle internetgerichte systemen met PHP, inclusief appliances, containerimages en applicaties van derden. Het NCSC verwijst daarvoor naar zijn technische overzichtspagina met PHP-gerelateerde producten.
2. Patch naar de juiste versie. Upgrade naar PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35, of installeer de update van uw distributie of LTS-leverancier. Herstart daarna alle workers.
3. Neem een besluit over wat niet direct kan. Het NCSC adviseert kwetsbare systemen offline te houden tot ze gepatcht zijn en per systeem een risicoafweging te maken. Leg die afweging vast, met naam en datum.
4. Bevraag uw leveranciers schriftelijk. Vraag welke PHP-versie ze draaien, wanneer ze patchen en hoe ze dat aantonen. Geen antwoord is ook een antwoord voor uw risicoregister.
5. Plan het einde van EOL-versies. Systemen op PHP 8.1 of ouder krijgen geen reguliere updates meer. Het PHP-project meldt bovendien dat PHP 8.2 op 31 december 2026 end-of-life is. Zet de migratie nu op de roadmap.
6. Organiseer capaciteit. Bepaal welke rollen u intern niet gevuld krijgt en schakel tijdig interim-specialisten in voor vulnerability management en DFIR.
7. Informeer het bestuur. Onder de Cyberbeveiligingswet is het bestuur eindverantwoordelijk. Een korte update met status, restrisico en besluiten voorkomt verrassingen later.

Onze visie: PHP2Shell is een stresstest voor uw securityorganisatie

Deze kwetsbaarheden laten zien hoe uw organisatie presteert onder tijdsdruk. Organisaties met een actuele asset-inventaris, vaste afspraken met leveranciers en een flexibele schil van securityprofessionals zijn binnen dagen klaar. Organisaties zonder die basis lopen weken achter en ontdekken pas tijdens de crisis waar de gaten zitten. Gebruik de evaluatie van deze week om structureel te regelen wat nu ontbrak, of het nu gaat om een interim CISO die de lijnen uitzet of een vulnerability management-team dat op sterkte wordt gebracht. Onze NIS2-pagina geeft een overzicht van wat de Cyberbeveiligingswet van uw organisatie vraagt.

Veelgestelde vragen

Welke PHP-versies zijn veilig tegen PHP2Shell?

Het PHP-project heeft de kwetsbaarheden opgelost in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Gebruikt u PHP via een Linux-distributie of LTS-leverancier, controleer dan het advies van die leverancier, omdat het versienummer van een gepatcht pakket kan afwijken. PHP 8.1 en ouder krijgen geen reguliere updates meer van het PHP-project.

Zijn de mitigaties voldoende als ik niet direct kan patchen?

Nee. Het PHP-project stelt dat de mitigaties alleen specifieke aanvalspaden beperken en een installatie niet veilig maken. Het NCSC noemt ze onvoldoende en adviseert kwetsbare systemen offline te houden tot ze gepatcht zijn. Alleen de update is een volledige oplossing.

Moet ik PHP2Shell melden onder de Cyberbeveiligingswet?

Een kwetsbaarheid op zich is geen incident. De meldplicht onder de Cyberbeveiligingswet geldt voor significante incidenten. Vindt u aanwijzingen dat een systeem daadwerkelijk is misbruikt, beoordeel dan direct of er sprake is van een significant incident en betrek uw jurist en uw CSIRT. Leg in alle gevallen vast welke maatregelen u wanneer heeft genomen.

Capaciteit nodig om PHP2Shell deze week af te ronden? MVPeople Group levert ervaren interim-specialisten in vulnerability management, DFIR en GRC. Neem contact op voor een eerste gesprek over uw situatie.