Jarenlang zat er een ernstig lek verstopt in PHP, de programmeertaal onder een groot deel van het web. Pas met hulp van krachtige AI-modellen konden onderzoekers bewijzen hoe gevaarlijk het werkelijk was. Het gevolg: DigiD, MijnOverheid en de Tweede Kamer gingen uit voorzorg offline en beheerders wereldwijd moesten in allerijl hun servers bijwerken. De belangrijkste les zit alleen niet in het lek zelf. Wat gebeurt er als het vinden van zo'n fout straks uren kost, terwijl het repareren nog altijd maanden duurt? Woensdag 21 oktober 2026 zullen veel systeembeheerders niet snel vergeten. DigiD, MijnOverheid, Overheid.nl, TweedeKamer.nl en de Belastingdienst waren enige tijd onbereikbaar, en ook Tweakers haalde zijn site uit voorzorg offline. De oorzaak heet PHP2Shell: twee
kritieke kwetsbaarheden in PHP, bekend als CVE-2026-109618 en CVE-2026-109619. Het PHP-beveiligingsteam geeft beide een ernstscore van 9,2 op een schaal van 10. Via de lekken kan een aanvaller zonder in te loggen op afstand code uitvoeren op een kwetsbare server. Inmiddels zijn de beveiligingsupdates beschikbaar en zijn de meeste overheidssites weer bereikbaar. Dat betekent alleen niet dat iedere kwetsbare server al is bijgewerkt.
Wie alleen naar de techniek kijkt, mist het grotere verhaal. De manier waarop deze kwetsbaarheden boven water kwamen, zegt veel over de toekomst van cybersecurity. Onderzoekers gebruikten geavanceerde AI-modellen om fouten te analyseren die al jaren in de
software zaten, en om er werkende aanvallen mee te bouwen. Werk dat voorheen veel tijd, kennis en geld kostte, gaat daardoor een stuk sneller. En precies daar begint een groter probleem.
AI bewees wat een audit in 2024 alleen kon vermoeden
PHP bestaat al ruim dertig jaar en is nog altijd de technische basis onder WordPress, Drupal, Joomla, Magento en talloze andere websites en applicaties. Je zou verwachten dat de kern van zo'n taal inmiddels grondig is doorgelicht. Toch zat het probleem in iets fundamenteels: de manier waarop PHP met geheugen omgaat als het verwerken van een verzoek onverwacht stopt, bijvoorbeeld door een geheugentekort. Volgens
Cloudflare ruimt PHP dat geheugen dan niet veilig op en gebruikt het daarna gegevens die niet goed zijn klaargezet of al zijn vrijgegeven. Beveiligingsbedrijf
Sansec stelt dat alle webservers met PHP 5.4 of nieuwer zijn geraakt. Die versie verscheen in 2012.
Drie partijen stuitten onafhankelijk van elkaar op het probleem. Beveiligingsbedrijf Calif en OpenAI meldden de kern van het lek op 11 augustus bij PHP, waarna Wiz op 24 augustus aanvullende aanvalsroutes rapporteerde. Wiz zette daarbij Gemini 4 Argon van Google, de eigen tool Wiz Atlas en GPT-5.6 Sol van OpenAI in,
meldt CNN. Het bedrijf, dat inmiddels eigendom is van Google, liet zien dat het lek zonder inlog misbruikt kon worden op standaardinstallaties van WordPress, Drupal en Joomla. Ook kon een aanvaller via het geheugenlek wachtwoorden, inlogtokens, API-sleutels en certificaten uit andere verzoeken buitmaken, zonder zelf code te hoeven uitvoeren. De onderzoekers van Wiz vergelijken PHP2Shell met Heartbleed, het lek dat in 2014 een groot deel van het versleutelde internetverkeer raakte.
Het opvallendste deel van het verhaal komt van de PHP Foundation zelf. In een uitgebreide
blogpost erkent de organisatie dat de eerste aanwijzingen voor een van de lekken al in 2024 opdoken, tijdens de eerste externe beveiligingsaudit van PHP in jaren. Die audit werd uitgevoerd door Quarkslab en gefinancierd door het Duitse Sovereign Tech Agency. Destijds werd een aanval wel theoretisch voor mogelijk gehouden, maar niemand vond een concrete route. De oplossingen die het team bedacht, dreigden bovendien bestaande software te breken, nieuwe mogelijkheden voor DoS-aanvallen te openen of aanpassingen te vereisen in extensies van derden. Het werk aan een fix kwam daardoor maandenlang niet van de grond. "
We gaan er niet omheen draaien: de vertraging was een structureel falen, veroorzaakt door zowel de besluitvorming van het beveiligingsteam als een gebrek aan middelen", schrijft de PHP Foundation.
Pas toen Calif aantoonde dat het lek zonder voorwaarden tot het uitvoeren van code op afstand leidde, kreeg het de hoogste prioriteit. Dat is misschien wel de belangrijkste les van deze crisis. Een beveiligingslek kan jarenlang bestaan zonder dat iemand precies weet hoe gevaarlijk het is. Komt die kennis plotseling beschikbaar, dan kan de impact op het internet enorm zijn.
Een rommelige bekendmaking en de eerste aanvalspogingen
Alsof de techniek nog niet ingewikkeld genoeg was, liep ook de bekendmaking uit de hand. PHP wilde de beveiligingsupdates op 22 oktober publiceren, maar op 20 oktober lekten de CVE-nummers al uit, met een onjuiste ernstscore van 10,0. Samen met die waarschuwing ging volgens Sansec ook een screenshot van een aanvalstool met de naam PHP2Shell rond. Daarna verscheen online een video van onderzoeker Kirill Firsov waarin de volledige aanvalsketen werd gedemonstreerd. En softwareleverancier
Chainguard publiceerde ruim zes uur voor de officiële release al images met de fix, waardoor iedereen de wijzigingen kon bestuderen terwijl anderen nog op de updates wachtten. De PHP Foundation vervroegde de publicatie daarop naar woensdag 21 oktober, 14.00 uur UTC. Dat gaf beheerders minder voorbereidingstijd, maar beperkte de periode waarin aanvallers konden profiteren van half-openbare informatie.
Niet iedereen werd overvallen. Cloudflare had al sinds begin oktober aan bescherming gewerkt en beveiligde klanten met zijn webfirewall vanaf 21 oktober 03.02 uur UTC standaard tegen PHP2Shell, ruim negen uur voor de publieke bekendmaking. Dat was geen overbodige luxe. "We zien de eerste aanvallen opduiken en passen onze bescherming aan zodra er nieuwe varianten verschijnen", zei Cloudflare-CTO Dane Knecht. Beveiligingsbedrijf watchTowr ziet actieve aanvalspogingen op beide lekken, al is een geslaagde inbraak tot nu toe niet bevestigd. Volgens Previdian lukte het aanvallers bij de waargenomen pogingen niet om PHP-code uit te voeren of bestanden te uploaden. Wel circuleren er op GitHub inmiddels verschillende zogenaamde proof-of-concepts. Tenable kon van geen enkele vaststellen dat die werkt en waarschuwt dat het om onbetrouwbare en mogelijk zelf kwaadaardige code kan gaan.
Snellere aanvallers, dezelfde kleine teams
Tot nu toe is dit vooral een verhaal over verdedigers die AI goed gebruikten. De lekken werden gemeld, gerepareerd en grotendeels gedicht voordat er bevestigd misbruik was. Maar dezelfde technologie werkt net zo goed voor de andere kant. Krachtige AI-modellen kunnen code doorgronden, fouten opsporen en helpen om er een werkende aanval van te maken. Dat betekent niet dat een beginnende hacker met een chatbot morgen een grote website binnendringt.
Opvallend genoeg zijn de modellen die Wiz gebruikte gewoon te koop: GPT-5.6 Sol is sinds juli breed beschikbaar en Gemini 4 Argon sinds half oktober voor betalende gebruikers. OpenAI en Google bouwen weliswaar filters in tegen schadelijk cybergebruik, en een betrouwbare aanval vraagt nog altijd om kennis, tooling en uitgebreide tests. Maar de drempel ligt steeds minder bij toegang tot de technologie en steeds meer bij expertise, en het tempo ligt hoger dan ooit.
PHP2Shell staat daarin ook niet alleen. In juli vond Searchlight Cyber met GPT-5.6 Sol al een kritieke aanvalsketen in WordPress, bekend als wp2shell. Kort na de publicatie daarvan zag Wiz aanvallers op grote schaal
webshells plaatsen op kwetsbare servers. Wanneer het minder tijd en geld kost om kwetsbaarheden te vinden en te misbruiken, worden aanvallen economisch aantrekkelijker. Ook systemen die voorheen te complex waren om aan te vallen, kunnen dan interessante doelwitten worden.
Aan de verdedigende kant verandert intussen veel minder. Het oplossen van de onderliggende problemen bleef bij PHP afhankelijk van een klein team van kernontwikkelaars met diepgaande kennis van de engine, die volgens de PHP Foundation ook nog eens talloze andere verantwoordelijkheden hebben. AI maakt het daarnaast makkelijker om software automatisch te doorzoeken en mogelijke lekken te melden. Iemand moet vervolgens nog altijd vaststellen of zo'n melding klopt, hoe ernstig het probleem is en welke oplossing veilig kan worden doorgevoerd. Het vinden versnelt, het repareren nauwelijks.
PHP is daarin geen uitzondering. Een groot deel van het internet draait op opensourcesoftware die door kleine groepen ontwikkelaars wordt onderhouden, terwijl techbedrijven, banken, overheden en hostingproviders er dagelijks op leunen. Dat model heeft het internet veel gebracht, maar de afhankelijkheid wordt steeds groter. De PHP Foundation zit inmiddels in het Patch the Planet-programma van OpenAI, waarbinnen Calif op 30 juli een audit van PHP begon, en roept bedrijven die op PHP draaien nadrukkelijk op om de beveiliging mee te financieren. Dat is geen overbodig verzoek: de audit uit 2024 kwam er alleen dankzij overheidsgeld uit Duitsland.
Wat dit vraagt van beheerders, bedrijven en overheden
Voor wie een website of server beheert, is de eerste stap eenvoudig. Het Nationaal Cyber
Security Centrum stelt dat elk systeem met PHP dat vanaf internet bereikbaar is vermoedelijk kwetsbaar is totdat het is bijgewerkt. Versies onder PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 zijn kwetsbaar. De versie kun je controleren in het hostingpanel of in WordPress via Extra en Sitediagnose. Na de update moet PHP ook daadwerkelijk opnieuw worden gestart. Let op als je PHP installeert via de veelgebruikte repository van Remi op RHEL-servers: daar was de fix op 21 oktober nog niet beschikbaar. Het Britse NCSC adviseert systemen die niet kunnen worden bijgewerkt, desnoods offline te halen. OpenAI bracht bovendien een Codex-skill uit waarmee beheerders kwetsbare PHP-versies kunnen opsporen.
Toch zou het verkeerd zijn om uit deze crisis te concluderen dat AI vooral een bedreiging is. Zonder het AI-ondersteunde onderzoek was het lek uit 2024 mogelijk nog veel langer blijven liggen, of was de werkelijke impact onderschat. AI geeft verdedigers de kans om bestaande software systematisch door te lichten, updates sneller te testen en verdachte activiteit eerder te herkennen. Organisaties kunnen daardoor vaker zelf op zoek gaan naar problemen, in plaats van te wachten tot iemand anders ze vindt of misbruikt.
Dat vraagt wel om investeringen: in beveiligingsteams, in het onderhoud van opensourcesoftware en in systemen die updates snel en betrouwbaar uitrollen. Regelmatig updaten en sterke wachtwoorden blijven belangrijk, maar zijn niet genoeg als fundamentele fouten in veelgebruikte software jarenlang onopgemerkt blijven. En grote bedrijven en overheden mogen zich hardop afvragen hoeveel ze zelf bijdragen aan de beveiliging van de software waarop hun digitale diensten draaien.
Wat we deze week zagen, is waarschijnlijk een voorproefje van een nieuw tijdperk, waarin AI niet alleen helpt om software te bouwen, maar ook om die software te doorgronden op manieren die voorheen nauwelijks mogelijk waren. De vraag is niet of AI het internet gevaarlijker maakt, maar of we AI snel genoeg inzetten om het veiliger te maken. Want als het ontdekken van beveiligingslekken straks uren kost, maar het oplossen ervan nog altijd maanden duurt, hebben we een probleem dat veel groter is dan PHP alleen.