Nee, de wereld staat niet in brand. Het internet blijft werken!

Geen succesvolle hack, wel een echt lek

Waren de afgelopen dagen dan volledig voor niets? Zijn er op zoveel plaatsen dan enorme fouten gemaakt? Nee, zeker niet. Integendeel.

Even terug naar het begin: een echt veiligheidsprobleem in PHP, eentje dat al sinds 2019 bekend was. Een bug die werd gevonden nog voor er AI-tools bestonden om ons werk te doen.

Die AI maakt de laatste maanden wel het verschil. Met haar bijna oneindige rekenkracht levert ze uren werk op waar je vroeger zelf nooit van zou dromen. Precies die evolutie toont aan dat het beschreven probleem echt relevant is.

Jarenlang was de consensus dat dit lek bijna onmogelijk te misbruiken was. Tijdens de zomervakantie bewezen enkele beveiligingsbedrijven het tegendeel: misbruik is wel degelijk mogelijk.

Waarom duurt het dan zo lang voor er echt ‘succes’ is, als we een gehackte server zo willen noemen? Is dit het higgsboson van de PHP-lekken?

De afgelopen dagen hebben ook wij mogelijke exploitcode getest en de aanvallen op al onze systemen geanalyseerd. En die aanvallen zijn er genoeg: miljoenen requests per uur hameren op alles wat op het internet staat.

Niets is succesvol. Websites blijven draaien, zoals je zelf wel ziet. De apocalyps blijft volledig uit.

Waarom blijft de apocalyps uit?

Je zou kunnen zeggen: dit lek bestaat niet en al die bedrijven zochten gewoon wat aandacht om weer eens AI te pushen. Dan moet ik je toch teleurstellen.

Het is echt en we hebben zelf ook een werkende proof of concept (PoC), eentje op basis van code die gewoon publiek beschikbaar is op GitHub.

En dan komt het ‘maar’, anders had ik deze tekst niet hoeven te schrijven. Al deze exploits komen voorlopig met een handleiding die uitlegt hoe je je server moet opzetten om het lek te laten werken. Een beetje de omgekeerde wereld, maar het helpt je wel te begrijpen welke risico’s je werkelijk loopt.

Sommige van deze instellingen zijn te technisch om hier diep op in te gaan en voor de meesten moeilijk te volgen, maar ze zijn wel enorm nuttig als achtergrond om de werkelijke context te begrijpen.

De meest voor de hand liggende is de memory limit van PHP, die behoorlijk beperkt moet zijn: ver onder wat de meesten op hun hosting krijgen. Het andere is de manier waarop PHP draait. PHP moet hiervoor als module van een Apache-webserver draaien, met bovendien een beperking op het aantal achterliggende processen.

Laat dat nu net configuratiekeuzes zijn die je de afgelopen 15 jaar normaal gesproken nooit bij een hostingprovider zou vinden. Daar draait PHP apart van de webserver en is de geheugenlimiet vrij hoog om moderne webapplicaties zoals WordPress en Drupal te kunnen draaien.

Wij bouwen omgevingen waarin meer dan één persoon tegelijkertijd je website kan bezoeken. En precies dat gooit momenteel flink roet in het eten van deze exploits.

Zeg ik nu eigenlijk: “Stop met die heisa, men overdrijft”? Nee, natuurlijk niet. Het probleem is bewezen en het is echt. Wat vertellen ze je er niet bij? Het rationele: de sterren moeten momenteel wel zeer gunstig staan voor de hacker.

Er zal waarschijnlijk ooit een werkende exploit komen. Dat kan heel snel gaan, misschien zelfs uren na deze publicatie, maar het kan evengoed nog eens zeven jaar duren. Het aantal tokens dat momenteel aan deze zoektocht wordt verbrand, zal wel enorm zijn.

Waarom ging iedereen dan op zwart?

Waarom ging iedereen dan op zwart en was dat een weloverwogen keuze? Daar is het misschien echt wat foutgelopen: niet-nagekomen afspraken over communicatie, een mediastorm en vooral veel mensen die goedbedoeld, met beperkte informatie, adviezen moesten geven en beslissingen moesten nemen.

De proportionaliteit van een maatregel moet altijd worden afgewogen tegen het werkelijke risico. Een beladen uitspraak. In dit geval geloof ik oprecht dat iedere regulator of cyberbeveiligingsautoriteit op basis van de informatie die voor hen beschikbaar was, een onderbouwde beslissing heeft genomen.

Die informatie was echt wel heel beperkt, midden in een mediastorm waarin maar al te graag het einde van de wereld werd aangekondigd. Daarnaast was er een megamarketingmachine van securitybedrijven die geld verdienen aan angst, en natuurlijk de AI-wereld, die meer en meer op zoek is naar argumenten voor haar enorme waarderingen. Ik zou niet in de schoenen willen staan van het CCB of CERT-EU.

Elk van deze partijen heeft natuurlijk een terecht punt in zijn argumentatie, maar neutrale berichtgeving is onbestaande in tijden van crisis.

Wist je dat? Diezelfde dag was er ook CVE-2026-111497, met de minder originele naam Node2Shell. Een probleem in Node.js, even belangrijk en gevaarlijk, maar toch genegeerd door de media. Zijn we hiervoor ook offline gegaan?

Paniekvoetbal? Ja, maar niet waar je denkt

Dan komt het woord ‘paniekvoetbal’ naar boven. Het zou spijtig zijn als er over enkele maanden zo op dit incident wordt teruggekeken. Ja, er was sprake van paniekvoetbal, maar eerder in de ondoordachte acties die we sommige partijen in onze sector zagen nemen.

Volgens de PHP Foundation was dit vanaf 11 augustus de topprioriteit. Meerdere mensen hebben aan de oplossing gewerkt, niet alleen tijdens hun werkuren, maar ook in het weekend en ’s avonds. Dat geeft ons een goed idee van hoe complex dit verhaal werkelijk was.

Dit is niet iets wat je ’s ochtends snel zelf oplost met enkele lijnen code, zonder de reikwijdte te kennen of enige ervaring te hebben met de bestaande PHP-codebase. Hetzelfde geldt voor het gebruik van code die anderen op GitHub beginnen te delen. Zonder een grondige analyse zorgen zulke acties uitsluitend voor extra beveiligingsrisico’s en brengen ze de stabiliteit van een complexe serveromgeving enorm in gevaar.

Gelaagde beveiliging: offline gaan hoeft niet

Is het gebruiken van de officiële patches dan de enige optie? Moet je offline gaan en dus afwachten? Gelukkig niet. Veiligheid vergt een gelaagde aanpak, en dat komt in dit geval goed van pas. Los van de mitigaties binnen PHP zelf, zoals configuratie-instellingen die op dat moment worden beschouwd als een tijdelijke oplossing om de getroffen functionaliteit uit te schakelen of te beperken, beschikken de meeste hostingpartijen over extra beveiligingslagen vóór en rond PHP zelf, bijvoorbeeld:

web application firewalls

beperkingen in de webserversoftware

systeembeveiliging vanuit de kernel

EDR-software

Daardoor is de kans klein dat kwaadaardige code via één lek op de server terechtkomt, laat staan dat die ook uitgevoerd wordt. Je hoeft dus echt niet ad hoc snel iets te bouwen om daar vervolgens de hele dag op te vertrouwen.

Het moment van de waarheid

Het moment van de waarheid: wanneer de informatie eindelijk online komt en duidelijk wordt wat er daadwerkelijk gepatcht wordt. Ook dit verloopt niet zonder slag of stoot. Er zijn twee pistes die dan spelen.

1. Het vage verdwijnt

Het wordt 100% duidelijk wat er echt speelde. Vanaf nu begint de klok ook echt te tikken. Waar je vooraf nog maar een paar slimme hackersgroeperingen en securitybedrijven had, krijg je nu te maken met een groot aantal hackers die koste wat kost als eerste een exploit willen ontwikkelen. Er is geen beter moment om bij bedrijven in te breken, je botnet uit te breiden en naam te maken.

Tegenwoordig is deze periode enorm kort geworden, met dank aan AI. De voorspellingen waren dat binnen 15 minuten een stortvloed aan bots aan de slag zou gaan. Een tweetal uur na de release sprak Cloudflare al over een explosie tot honderdduizenden pogingen.

2. Iedereen krijgt toegang tot de patches

Dat betekent niet dat iedereen meteen kan patchen en weer online kan gaan. Wat je wel snel te weten komt, is of de mitigaties toereikend zijn of niet. Je kan een evaluatie maken en met een plan komen, deze keer niet op basis van geruchten, maar op basis van feiten.

Een les over onze supply chain

Over dat patchen moeten we het toch nog even hebben. Hier zit een les, niet alleen voor ons, maar ook voor de rest van de sector. Een evaluatie van de supply chain, iets wat mensen met wat NIS2-ervaring wel zullen kennen.

Voor software die zo belangrijk is voor onze sector vertrouwen we, net als heel wat andere ondernemingen, op opensourceprojecten van enkelingen. De Linux-distributies krijgen hun gepatchte PHP-versies vrij snel online, maar eigenlijk gebruikt bijna niemand die.

In onze sector vertrouwt men vaak op de repositories van Ondřej Surý of Remi Collet. Deze maken het mogelijk om verschillende versies van PHP op een uniforme manier op verschillende versies van je Linux-distributie te draaien. Dat zorgt voor flexibiliteit bij de klant en minder werk in het beheer.

Daar zit een extra vertraging. Deze vrijwilligers, die een enorme bijdrage aan de sector leveren, beginnen meestal pas na de officiële softwarereleases met hun werk. Het herbouwen van hun packages duurde enkele uren en ging telkens gepaard met overbelaste downloadservers. Wie moest vertrouwen op het updatecommando van zijn Linux-server, was tot diep in de nacht zoet.

Gelukkig hebben wij niet zo lang moeten wachten, maar we zien wel de noodzaak om ook de buildmethodes zelf open source te maken. Deze maken we de komende dagen voor iedereen beschikbaar. Onze build van deze PHP-versies kan je vandaag al downloaden via onze publieke mirrors, ook voor je oudere Ubuntu-servers.