Wat is PHP en wat was het probleem?

PHP is een programmeertaal voor websites en webapplicaties. WordPress-sites, webshops, klantportalen en veel interne webtoepassingen draaien erop. Volgens gangbare schattingen gaat het om ongeveer 70% van alle websites waarvan bekend is welke techniek ze gebruiken.

In PHP zaten twee fouten in de manier waarop de software intern met geheugen omgaat. Met een speciaal opgesteld verzoek kon een aanvaller een server overnemen, zonder in te loggen. Beide lekken kregen een ernstscore van 9,2 op 10. De fouten zaten al sinds 2012 in de code.

Een bekend probleem dat werd onderschat

Een ontwikkelaar van PHP zag het geheugenprobleem al in 2024. Toen vond niemand een manier om het te misbruiken. Elke mogelijke oplossing had bovendien nadelen, dus bleef het liggen. De PHP Foundation erkent nu zelf dat die vertraging een structurele fout was.

In augustus 2026 vonden meerdere beveiligingsonderzoekers, los van elkaar en met hulp van AI, wel een werkende aanvalsroute. Samen met de makers van PHP en grote partijen als Microsoft, Google, AWS en Cloudflare werkten zij daarna aan een oplossing, volgens de gebruikelijke afspraken in de beveiligingswereld. Zo krijgen verdedigers een voorsprong op aanvallers.

Hoe een kritieke update normaal verschijnt

Bij software die zo veel wordt gebruikt, kun je een oplossing niet zomaar op een willekeurig moment online zetten. Criminelen vergelijken dan de oude en de nieuwe versie, zien precies wat er is gerepareerd en kunnen met hulp van AI soms binnen een paar uur een aanval bouwen.

Daarom plannen de makers zo'n release onderling, samen met de partijen die de software verspreiden, zoals Linux-distributies en hostingbedrijven. Zij krijgen de oplossing vooraf. Kort van tevoren volgt een openbare aankondiging: op dat tijdstip komt een kritieke update, zorg dat uw beheerder klaarstaat. Zo blijft de periode waarin aanvallers de update kunnen bestuderen terwijl systemen nog kwetsbaar zijn, zo kort mogelijk.

Wat er dit keer misging

De release stond gepland voor donderdag 22 oktober. Op dinsdag 20 en woensdag 21 oktober ging het op meerdere punten mis:

  • De nummers van de kwetsbaarheden gingen rond op online forums en sociale media, met een te hoge ernstscore. Technische details waren er nog niet. PHP vervroegde de release daarop naar woensdag 21 oktober.
  • Die avond plaatste een van de bureaus die de lekken had ontdekt per ongeluk een video van een werkende aanval. De video is verwijderd, maar kopieën bleven rondgaan en hielpen anderen op weg.
  • Woensdagochtend publiceerde een beveiligingsbedrijf de gerepareerde software al ruim zes uur voor de afgesproken tijd, in strijd met de afspraken. Daarmee kon iedereen zien wat er was aangepast.

De updates kwamen woensdag rond 16:00 uur. Tot dat moment hadden aanvallers aanwijzingen om mee aan de slag te gaan, terwijl beheerders nog niets konden installeren. Bij de release had PHP nog geen werkende aanvallen vastgesteld. Cloudflare zag diezelfde middag wel de eerste aanvalspogingen, en Tweakers telde in de eigen logs meer dan honderd scans op het lek.

Uitzetten of afwachten?

Beheerders moesten die woensdag beslissen met weinig informatie. Er waren geen technische details, alleen de ernstscore en het advies van het Nationaal Cyber Security Centrum (NCSC), dat waarschuwde dat aanvallers systemen op afstand konden overnemen. De keuze was: afwachten en hopen dat het goed gaat, of systemen uit voorzorg offline halen.

Hoe belangrijker een systeem, hoe sneller u voor uitzetten kiest. Een website met alleen informatie en zonder webshop is minder kritiek dan het inlogsysteem van DigiD. Toch is een kleine website niet veilig omdat hij klein is: aanvallers zoeken automatisch naar kwetsbare servers, en een overgenomen server kan worden gebruikt voor van alles.

Dat zoveel sites tegelijk uit de lucht gingen, kwam niet door een centrale opdracht. Duizenden beheerders kwamen op basis van dezelfde informatie los van elkaar tot hetzelfde besluit.

Wat NETW voor u heeft gedaan

Bij een situatie als deze merkt u als het goed is weinig van ons, en dat is precies de bedoeling. Wij volgen beveiligingsupdates doorlopend. Ze verschijnen bijna wekelijks en regelmatig zit er een kritiek lek bij. Die installeren we zodra dat nodig is, naast het normale onderhoud, zonder dat u daar iets voor hoeft te doen.

Deze update stond binnen 15 minuten na publicatie op de servers die wij beheren. We zien geen aanwijzingen dat er misbruik is gemaakt. Toen het lek naar buiten kwam, hebben we de monitoring verscherpt, en die houden we de komende tijd hoger. Heeft u vragen over uw eigen situatie? Dan kunt u altijd bij ons terecht.

Waarom dit vaker gaat gebeuren

AI maakt het veel makkelijker en sneller om fouten in software te vinden. Dat geldt voor onderzoekers die lekken willen dichten, maar ook voor criminelen die ze willen misbruiken. Fouten die jarenlang als onschuldig golden, blijken met AI ineens wel bruikbaar voor een aanval. Er liggen er daarvan nog veel meer, in allerlei software.

De tijd tussen het verschijnen van een update en de eerste aanvallen wordt dus korter. Waar beheerders vroeger een paar dagen hadden, gaat het nu om uren. Systemen offline halen wordt daardoor vaker de verstandige keuze. Op de lange termijn helpt AI ook om betere en veiligere software te maken, maar de komende tijd moeten we rekening houden met meer van dit soort situaties.

Wat kunt u doen?

  1. 1

    Weet waar uw websites en webapplicaties draaien

    Weet ook wie ze beheert. Denk aan uw website, webshop, klant- of leveranciersportalen en andere webapps. Sommige daarvan staan bij een webbureau of hostingpartij en niet bij ons.

  2. 2

    Vraag of de update is geïnstalleerd

    Veilige versies zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35, of de gepatchte versie van de Linux-distributie of andere bronnen. Voor PHP 8.1 en ouder is er geen officiële update; die systemen moeten worden bijgewerkt naar een nieuwere versie. Dat gaat om minstens een kwart van alle PHP-websites, en zo'n upgrade kan technisch complex zijn. Wacht daar dus niet mee tot het volgende lek.

  3. 3

    Spreek vooraf af wie mag besluiten een systeem uit te zetten

    Ook buiten kantooruren. Als het moment daar is, wilt u geen tijd verliezen aan het zoeken van toestemming. Voor systemen die bij NETW draaien, ontzorgen wij u hierin.

  4. 4

    Bepaal per systeem hoe kritiek het is

    Dan weet u bij een volgend lek meteen wat eerst offline moet en wat kan blijven draaien.

U hoeft dit niet alleen uit te zoeken. Ook voor websites en diensten die u niet bij NETW afneemt, kunnen wij dit voor u oppakken: we brengen in kaart wat er draait, stemmen af met uw hostingpartij en softwareleveranciers en controleren of de update is geïnstalleerd.

Bronnen

Hulp nodig?

Draait er ergens een PHP-versie die niemand bijhoudt?

Wij brengen uw websites en webapplicaties in kaart, stemmen af met uw hostingpartij en controleren of de update is geïnstalleerd. Neem contact op, dan bespreken we wat er in uw situatie nodig is.

Neem contact op Bekijk onze diensten