PHP2Shell: wat de PHPocalypse ons leert over afhankelijkheden, snelheid en vertrouwen

Door Adem Ozdemir

De dag dat het web de stekker eruit trok

Op woensdag 21 oktober 2026 gingen in Nederland en België honderden websites uit voorzorg offline. Tweakers, RTL Nieuws, MijnOverheid, DigiD en alle Vlaamse overheidssites gingen op zwart. De reden: twee kritieke lekken in PHP, de taal waar bijna 70 procent van alle websites op draait.

Rond 16.00 uur Nederlandse tijd kwamen de patches uit en kwam het web langzaam weer tot leven. Tweakers doopte het de PHPocalypse. Wat ons betreft is het vooral een les over iets waar wij dagelijks mee werken: afhankelijkheden die je niet ziet, totdat ze omvallen.

Wat is PHP2Shell?

PHP2Shell is de naam voor twee samenhangende lekken waarmee een aanvaller zonder in te loggen eigen code op een server kan uitvoeren. Beide scoren 9,2 op 10 (CVSS 4.0) en zitten al in PHP sinds versie 5.4 uit 2012.

LekWat er misgaatBevestigd effect
CVE-2026-109618Een verzoek raakt precies op het verkeerde moment de geheugenlimiet. PHP laat half opgebouwde data achter en gebruikt die later alsof die klopt.Op Apache met mod_php werkt het al vóór er applicatiecode draait, met standaardinstellingen. Ook op PHP-FPM bevestigd.
CVE-2026-109619Een fatale fout laat een verwijzing achter naar geheugen van een vorig verzoek. Het volgende verzoek gebruikt dat vrijgegeven geheugen.Code uitvoeren aangetoond tegen een echte applicatie op Apache met mod_php.

De lekken zitten in geheugenbeheer en foutafhandeling: onderdelen die bijna elk verzoek raakt. Daardoor waren ze ernstig en lastig te repareren zonder iets anders te breken.

Opvallend is hoe ze boven water kwamen. Volgens de PHP Foundation was de kern van het probleem al in 2024 in beeld, tijdens een externe audit. Pas toen meerdere onderzoeksteams deze zomer, deels met AI-tools, een werkende aanvalsroute vonden, werd duidelijk hoe groot het was. AI vindt bugs sneller dan ooit, voor verdedigers én voor aanvallers.

Hoe een zorgvuldig plan in twee dagen uit de bocht vloog

De patch stond gepland voor donderdag 22 oktober, maar kwam een dag eerder uit omdat informatie te vroeg naar buiten kwam. Wekenlang werkten tientallen partijen onder embargo samen. Dat ging goed tot twee dagen voor de release.

Moment (NL-tijd)Wat er gebeurde
wo 21 okt, ca. 16.00PHP brengt 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uit. Sites komen weer online.
wo 21 okt, 09.41Een distributeur publiceert al images met de fix, ruim zes uur voor de afgesproken release.
wo 21 okt, overdagEerste exploitcode circuleert, bots scannen inlogpagina’s van CMS’en. Veel organisaties gaan offline.
di 20 okt, ca. 22.00Een van de betrokken onderzoeksbureaus zet per ongeluk een video van een werkende aanval online. Hij wordt verwijderd, maar kopieën gaan rond.
di 20 okt, 21.30PHP vervroegt de aankondiging en verschuift de release een dag naar voren.
di 20 okt, ca. 17.00De twee CVE-nummers duiken op in forums en social media, met een verkeerde score van 10,0. Technische details lekken niet.
11 augMeerdere onderzoekers melden onafhankelijk van elkaar een werkende aanvalsroute. Repareren wordt topprioriteit.

We noemen hier bewust geen namen. Achteraf is het makkelijk wijzen. Maar wie weleens een live-omgeving heeft gedeployed vlak voor een deadline, weet hoe snel één knop, één verkeerd kanaal of één automatische pipeline het verschil maakt. Iedereen is een keer aan de beurt.

Waarom raakt dit zoveel organisaties?

PHP draait volgens W3Techs op 69,3 procent van alle websites, en ruim een derde van die sites draait een versie die officieel geen updates meer krijgt. WordPress, Drupal, Joomla, Magento, Laravel en Symfony zijn allemaal PHP.

Het echte probleem is dat veel organisaties niet weten waar PHP bij hen draait. Een lezer op Tweakers beschreef het treffend: hij draaide Nextcloud en Jellyfin, en moest opzoeken welke van de twee PHP gebruikte. PHP zit ook in beheerinterfaces van routers, NAS-systemen en andere apparaten, en in tools die je als dienst afneemt.

En zelfs als je het weet, ben je vaak afhankelijk van anderen. Een fix moet van PHP naar een Docker-image, naar een afgeleid image, naar de leverancier van je software en pas dan naar jou. Op shared hosting wacht je op je hostingpartij. Elke schakel kost tijd, terwijl een aanvaller met AI in een middag een exploit in elkaar zet.

Wat moet je nu doen?

Patchen is de enige echte oplossing; workarounds kopen alleen tijd. Dat zeggen de PHP-ontwikkelaars zelf ook.

  1. Breng in kaart waar PHP draait: websites, webshops, interne tools, beheerinterfaces van apparaten en SaaS-diensten die je afneemt.
  2. Update naar 8.2.35, 8.3.36, 8.4.27 of 8.5.12. Op Debian en Ubuntu gaat dat via je package manager; controleer daarna de versie.
  3. Draai je 8.1 of ouder? Plan een upgrade. Voor 7.4, 8.0 en 8.1 bestaan broncode-backports en sommige LTS-leveranciers bieden patches, maar dat is een noodverband.
  4. Op shared hosting: vraag je hostingpartij of je PHP-versie al gepatcht is. Een WordPress-update lost dit lek niet op, het zit in de server.
  5. Kun je nog niet patchen? Overweeg tijdelijk offline gaan, multipart-POST blokkeren waar je geen uploads nodig hebt of extra regels in je WAF. Behandel dat als overbrugging.
  6. Controleer na het patchen of er niet al iemand binnen is: onbekende bestanden, gewijzigde pagina’s, nieuwe beheerders. Een patch sluit de deur, maar zet niemand buiten.

Voor actuele adviezen zijn het NCSC en de aankondiging op php.net de beste bronnen.

Wat dit met automatisering en integratie te maken heeft

PHP2Shell is geen PHP-verhaal, het is een afhankelijkhedenverhaal. En daar draait ons werk bij Novictus om: processen en systemen zo inrichten dat je weet wat waarmee verbonden is, en dat je snel kunt bijsturen als er iets omvalt.

Weet wat je draait. De organisaties die vandaag snel konden schakelen, hadden een actueel overzicht van hun applicaties, versies en koppelingen. In ons Automation Volwassenheidsmodel is dat een van de eerste dingen waar we naar kijken. Zonder dat overzicht begint elk incident met zoeken in plaats van handelen.

Integraties zijn ook afhankelijkheden. Elke koppeling tussen CRM, ERP, website en formulieren is een plek waar data stroomt. Gaat een systeem offline, dan wil je weten welke processen stilvallen en welke data je opnieuw moet verwerken. Een goed ingericht integratieplatform maakt dat zichtbaar, met monitoring, logging en de mogelijkheid om taken opnieuw af te spelen.

Automatiseer het saaie, zodat mensen het belangrijke doen. Updates uitrollen, versies controleren en alerts doorzetten naar de juiste persoon zijn klussen die je kunt automatiseren. Dan houden je mensen tijd over voor de beslissingen die echt menselijk zijn: offline gaan of niet, wat zeggen we tegen klanten.

AI werkt twee kanten op. Dezelfde AI-tools die deze lekken hielpen vinden, helpen aanvallers ze te misbruiken. Dat maakt AI-geletterdheid geen hype, maar basiskennis voor iedereen die over IT-risico’s beslist.

De Organisatie van de Toekomst is niet de organisatie die nooit geraakt wordt. Het is de organisatie die binnen een middag weet waar ze kwetsbaar is, wat er moet gebeuren en wie het doet.

Iedereen is een keer aan de beurt

Vandaag was het PHP, eerder waren het Log4j, MOVEit en de grote hacks bij Nederlandse bedrijven. Morgen is het iets anders. De vraag is niet of jouw stack ooit geraakt wordt, maar hoe snel je weet wat je moet doen als het zover is.

Hulde aan alle beheerders, ontwikkelaars en hostingpartijen die vandaag (en vannacht) doorwerkten om het web weer veilig online te krijgen.

Wil je weten hoe goed jouw organisatie in staat is om zo’n dag op te vangen?

Neem contact met ons op voor een gesprek over je automatisering en integraties.

Bronnen

Download onze whitepaper

Lees over de 7 kansen voor low-code integration en hoe je deze kunt benutten. Benieuwd naar onze aanpak? Lees onze blogs en zie hoe bedrijven net als het jouwe profiteren van de oplossingen van Novictus.

Vragen? We helpen je graag. Neem contact met ons op!