Lek in PHP zelf: websites gingen uit voorzorg offline
Op 21 oktober kwam PHP met een update voor twee kritieke lekken. Het NCSC raadde aan elke website met PHP als kwetsbaar te behandelen tot die update erop staat.
Wat er gebeurde
Op 21 oktober bracht PHP een update uit voor twee lekken waarmee een aanvaller zonder in te loggen een webserver kan overnemen. Omdat er al een dag eerder details rondgingen, haalden organisaties in heel Europa hun websites uit voorzorg offline.
PHP kondigde de update op 20 oktober aan voor de volgende middag, 16.00 uur Nederlandse tijd, en gaf beide lekken een 9,2 op een schaal van 10. Rond 17.00 uur gingen de officiële nummers van de lekken al rond op fora en sociale media, met een verkeerde tijd en een te hoge score. ’s Avonds zette Calif, een van de bedrijven die de lekken vonden, per ongeluk een video online van zijn aanval op echte websites. Kopieën bleven rondgaan, meldt de PHP Foundation.
Op 21 oktober zag Cloudflare om 9.43 uur de eerste aanvallen. Vanaf 12.48 uur gingen onder meer DigiD, MijnOverheid, de Tweede Kamer, RTL, de KNVB en websites van ziekenhuizen op zwart. In Vlaanderen gingen alle websites van de overheid offline.
Rond 16.00 uur kwamen PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12 uit. ’s Avonds kwamen de meeste sites terug: MijnOverheid om 18.11 uur, DigiD om 20.27 uur.
Hoe groot de schade is, is nog niet duidelijk. Volgens Fortune telde Cloudflare binnen drie kwartier nadat het nieuws naar buiten kwam tienduizenden aanvalspogingen, en op de avond van 21 oktober miljoenen. AWS zag al dagen eerder pogingen en spreekt van misbruik op grote schaal. Het NCSC en minister Van Weel van Justitie zagen die dag in Nederland nog geen actief misbruik.
Behandel elke website met PHP als kwetsbaar tot de update erop staat.
Het advies van het NCSC van 21 oktober 2026, samengevat
De achtergrond
Hoe het lek werkt
PHP handelt elk verzoek aan een website af in een werkproces, dat daarna het volgende verzoek oppakt. Elk verzoek krijgt een eigen stuk geheugen, dat na afloop wordt opgeruimd. Het gaat mis als een verzoek halverwege wordt afgebroken, bijvoorbeeld omdat het meer geheugen vraagt dan mag. PHP stopt dan voordat alles is opgeruimd, en sommige verwijzingen wijzen nog naar geheugen dat al is vrijgegeven. Het volgende verzoek in hetzelfde werkproces gaat daar gewoon mee aan de slag.
Met een slim gekozen reeks verzoeken kan een aanvaller zo geheugen uitlezen, met daarin misschien wachtwoorden en sleutels van anderen, of eigen code laten uitvoeren. De aanval loopt via het soort verzoek waarmee je een formulier of bestand verstuurt, en dat verwerkt PHP nog voordat de code van de website zelf draait. Volgens Wiz kan daarom zelfs een testpagina die alleen ‘Hello World’ laat zien kwetsbaar zijn. Het risico is het grootst als PHP als module in webserver Apache draait (mod_php).
Met AI gevonden, na veertien jaar
De kwetsbare code zit sinds versie 5.4 uit 2012 in PHP. In 2024 zag een ontwikkelaar het geheugenprobleem al, bij het werk aan de eerste externe beveiligingsaudit van PHP, maar niemand vond toen een manier om het te misbruiken.
Calif, dat meedoet aan het programma Patch the Planet van OpenAI, vond op 1 augustus met het AI-model GPT-5.6 Sol het eerste lek en meldde het op 11 augustus; OpenAI meldde dezelfde dag dezelfde oorzaak. Wiz vond los daarvan op 19 augustus zijn eerste lek, met Gemini 4 Argon van Google, GPT-5.6 Sol en een eigen AI-tool. Volgens Wiz deed AI het geduldwerk: de aanval aanpassen aan elke PHP-versie en elke opstelling. Zo deed één onderzoeker in een week wat een topteam vroeger maanden kostte.
Eerdere lekken in PHP
PHP had vaker ernstige lekken, maar die raakten bepaalde opstellingen. In 2024 vond onderzoeker Orange Tsai op Windows een weg om een reparatie uit 2012 heen, in de CGI-stand, een oudere manier om PHP te draaien. Twee dagen na de update gebruikte de ransomwaregroep TellYouThePass dat lek al.
Dit keer gaat het om elke installatie die webverzoeken afhandelt. Volgens W3Techs draait 69,3 procent van de websites op PHP, gerekend over de sites waarvan bekend is waarop ze draaien. Daarvan gebruikt 65,3 procent versie 8, 26,9 procent versie 7 en 7,7 procent nog versie 5. PHP brengt alleen voor 8.2 en nieuwer zelf updates uit.
Onze analyse
Het vinden ging met AI, het dichten bleef mensenwerk
Met AI vonden twee bedrijven binnen drie weken hetzelfde lek, dat veertien jaar onopgemerkt was gebleven. Het dichten duurde ruim twee maanden. De PHP Foundation noemt dat zelf een structurele fout: een klein team moest het helemaal eens worden over reparaties die elk een nieuw probleem gaven, en had te weinig mensen. AI helpt verdedigers én aanvallers lekken sneller te vinden, maar de software onder een groot deel van het web rust op een handvol betaalde ontwikkelaars en vrijwilligers. Onze inschatting: er komen meer van zulke lekken in oude fundamenten, en de tijd tussen bekendmaking en aanval wordt korter.
Tegelijk is ‘70 procent van het internet’ te groot. Dat getal is het aandeel van PHP, niet het aantal websites dat je zo kunt overnemen. Volgens Sansec werkt de openbare aanvalscode op een standaardinstallatie meestal niet, en heeft een aanvaller meestal nog een tweede lek in de website nodig. Miljoenen pogingen zijn dus geen miljoenen inbraken. Maar een werkende aanval op mod_php bestaat, en uitgelezen geheugen kan wachtwoorden en sleutels prijsgeven.
Het grootste risico zit in oude versies. Ruim een derde van de PHP-sites draait op versie 7 of ouder. Voor 7.4, 8.0 en 8.1 bracht PHP alleen een reparatie in broncode uit, geen kant-en-klare update, en voor nog oudere versies niets. Wie daarop draait, hangt op zo’n dag af van een hoster of leverancier die zelf een reparatie inbouwt, of staat met lege handen.
Wat opvalt
- De vinders gaven de aanval weg Calif zette per ongeluk een video van zijn aanval online. Softwareleverancier Chainguard bracht ruim zes uur te vroeg gerepareerde versies uit, die aanvallers naast de oude konden leggen.
- Grote partijen waren voorbereid Cloudflare, AWS en Microsoft bereidden volgens Wiz vooraf afweer voor, en Linux-distributies kregen de reparatie eerder. Een bron van PHP-pakketten die een vrijwilliger bijhoudt, had die dag niets.
- Voortaan stemt PHP Het beveiligingsteam besluit voortaan bij meerderheid. De PHP Foundation vraagt bedrijven, hosters en overheden het werk mee te betalen.
- De meldingen stapelen zich op Sinds begin juli bracht PHP 15 lekken naar buiten en werkte het meer dan honderd ongeldige of dubbele meldingen weg, met een klein groepje ontwikkelaars.
Wat het voor jou betekent
Draait jullie website, webshop of klantportaal op PHP? Dan is hij kwetsbaar tot de update erop staat.
- Het lek zit in PHP zelf Een update van WordPress of plugins helpt dus niet. Alleen de nieuwe PHP-versie maakt het dicht.
- Vraag welke versie er draait Je hoster of bouwer kan je dat zo vertellen. Lager dan de versies hierboven? Dan moet er nu iets gebeuren.
- Pas op met mails van je hoster Criminelen doen zich voor als hoster en vragen om inloggegevens. Log altijd zelf in, via de weg die je kent.
Wat wij ermee kunnen · Ondersteuning
We kijken met je na of jullie sites al veilig zijn
Sites die bij ons staan, kregen de update dezelfde dag. Staat jullie site ergens anders, dan kijken we met je mee welke PHP-versie er draait en wat er moet gebeuren. Met Ondersteuning bewaken we daarna de lekken in wat jullie collega’s zelf bouwen.
Weet je niet zeker of jullie site al is bijgewerkt?
Stuur ons het adres van de site. We kijken met je mee en reageren altijd binnen één werkdag.
