Een bericht waar je liever niet mee wakker wordt
Woensdagochtend 21 oktober. We lezen dat het PHP-beveiligingsteam 's nachts twee kritieke kwetsbaarheden heeft aangekondigd: CVE-2026-109618 en CVE-2026-109619.
Allebei met een CVSS-score van 9,2 op 10.
De technische details zijn nog geheim. Die worden pas om 16:00 uur bekendgemaakt, tegelijk met de beveiligingsupdates.
We weten dus dát er iets ernstigs aan de hand is, maar nog niet precies wat. Of welke maatregelen voldoende bescherming bieden.
En PHP is niet zomaar een stukje software. Het vormt de basis van een enorm deel van het internet. WordPress-websites, webshops, SaaS-applicaties en grote maatwerkplatforms: ze draaien er allemaal op.
Het is meteen duidelijk dat dit een pittige dag gaat worden: wij hosten er duizenden.
De belangrijkste deadline staat vast: 16:00 uur. Tegen die tijd moeten we, net als de rest van de wereld, voorbereid zijn op de bekendmaking van de kwetsbaarheden en klaarstaan om de beveiligingsupdates uit te rollen.
09:35 uur. Klanten informeren, ook al is nog veel onduidelijk
Om 09:35 uur sturen we het eerste bericht naar klanten.
We vertellen dat er een kwetsbaarheid in PHP is gevonden, wat al bekend is, wat we nog niet weten en dat er mogelijk spoedonderhoud aankomt. Daarbij beloven we later die dag hoe dan ook een update te sturen.
Wat ons betreft is communicatie tijdens een beveiligingsincident minstens zo belangrijk als het technische werk. Achter iedere website of applicatie zit een organisatie die afhankelijk is van de beschikbaarheid ervan. Een webbureau moet zijn klanten kunnen informeren. Een SaaS-bedrijf moet weten wat het zijn gebruikers kan vertellen. En als een webshop mogelijk offline moet, wil je daar - ook onder tijdsdruk - op voorbereid zijn.
Ondertussen volgen onze engineers de officiële communicatie van PHP en andere beveiligingskanalen. We proberen zoveel mogelijk informatie te verzamelen voordat de technische details openbaar worden.
11:21 uur. Hoeveel functionaliteit moet je preventief uitschakelen?
In de loop van de ochtend verschijnen op beveiligingskanalen aanwijzingen over mogelijke aanvalsmethoden.
De informatie is nog niet officieel bevestigd. Toch geeft die ons, net als veel andere beheerders, voldoende aanleiding om preventieve maatregelen te nemen.
We besluiten twee PHP-functionaliteiten uit te schakelen:
session.upload_progress: de functionaliteit waarmee PHP de voortgang van bestandsuploads kan bijhouden.- De verwerking van
multipart/form-data: een veelgebruikte manier om formuliergegevens en bestanden naar een website of applicatie te versturen.
Vooral die tweede maatregel is ingrijpend.
Denk aan een webshop waar klanten geen bestanden meer kunnen uploaden, een contactformulier dat niet meer werkt of een SaaS-applicatie waarvan een belangrijke functie afhankelijk is van bestandsuploads.
Aan de ene kant moeten de websites en applicaties van onze klanten zo goed mogelijk functioneren.
Aan de andere kant zijn er serieuze aanwijzingen dat juist deze PHP-functionaliteiten een rol kunnen spelen bij het misbruiken van de kwetsbaarheden. Gezien de verwachte ernst ervan vinden we het risico te groot om niets te doen.
Het is een ingewikkelde afweging, maar uiteindelijk is duidelijk: dit is de enige verantwoorde beslissing.
We besluiten ook ons eigen beheerplatform, dat eveneens in PHP is gebouwd, tijdelijk offline te halen. Klanten kunnen ons ondertussen blijven bereiken via e-mail en telefoon.
De situatie wordt steeds grimmiger
Naarmate de middag vordert, wordt duidelijk hoe uitzonderlijk de situatie is.
Onder andere DigiD.nl, RTL.nl en MijnOverheid.nl gaan uit voorzorg offline. Op steeds meer plekken worden ingrijpende maatregelen genomen.
Het nieuws haalt de landelijke media.
Er zijn serieuze zorgen dat aanvallers al binnen enkele minuten na de officiële bekendmaking misbruik kunnen maken van de kwetsbaarheden. Er wordt zelfs gesproken over een tijdsbestek van slechts een kwartier.
Dat geeft beheerders bijzonder weinig tijd om de technische details te bestuderen, beveiligingsupdates te installeren en vervolgens te controleren of alles veilig is.
Offline gaan of online blijven? We helpen klanten de risico’s afwegen
Ondertussen krijgen we vragen van klanten. Moeten onze applicaties ook offline? Hoe groot is het risico als een applicatie grotendeels achter een login zit?
Dat laatste is bijvoorbeeld relevant voor SaaS-applicaties die alleen toegankelijk zijn voor ingelogde gebruikers.
Zolang de technische details ontbreken, kunnen we niet beoordelen welke applicaties daadwerkelijk kwetsbaar zijn. En een loginpagina biedt niet noodzakelijk bescherming. Ook zonder in te loggen kan een aanvaller immers verzoeken naar een applicatie sturen. Afhankelijk van de aard van de kwetsbaarheid kan dat al voldoende zijn.
Het eerlijke antwoord is dus: zolang het PHP-beveiligingsteam de details niet bekendmaakt, weten we het niet.
CERT-EU, het Computer Emergency Response Team van de Europese Unie, adviseert organisaties inmiddels om te overwegen publiek toegankelijke applicaties tijdelijk van het internet af te schermen.
Ons advies is dan ook duidelijk: beschouw je PHP-applicaties voorlopig als potentieel kwetsbaar. Als de mogelijke gevolgen van misbruik onacceptabel zijn, haal ze dan tijdelijk offline.
Voor een informatieve website is een paar uur onbereikbaarheid misschien vervelend, maar te overzien. Voor een SaaS-applicatie waar duizenden mensen op vertrouwen, ligt dat anders.
Daarom denken we met klanten mee over hun specifieke situatie. We leggen uit wat we weten, welke risico’s we zien en waarom bepaalde maatregelen verstandig kunnen zijn. Waar nodig kunnen we hun applicaties op infrastructuurniveau offline halen.
De uiteindelijke risicoafweging laten we op dat moment bewust bij klanten. Je kunt immers zelf het beste beoordelen welke gevolgen een onderbreking heeft voor de eigen organisatie en gebruikers, en op basis daarvan, of offline gaan juist wel of niet verantwoord is.
Ondertussen blijven we de ontwikkelingen nauwgezet volgen. We houden niet alleen de officiële beveiligingskanalen in de gaten, maar ook de informatie die via andere kanalen mondjesmaat naar buiten komt.
Naarmate 16:00 uur dichterbij komt, wordt het steeds moeilijker om het online houden van de applicaties nog te verantwoorden.
14:57 uur. Dit voelt heel tegennatuurlijk.
Websites, webshops en applicaties van webbureaus, SaaS-bedrijven en grote platforms snel, veilig en betrouwbaar laten draaien: daar werken we iedere dag aan.
Nu besluiten we ze allemaal uit te zetten.
Om 14:57 uur informeren we onze klanten dat we om 15:15 uur alle omgevingen op Cyberfusion Core tijdelijk offline halen.
Eerder die middag lieten we de uiteindelijke afweging nog bij onze klanten. Maar de tijd verstrijkt, de technische details blijven onbekend en de dreiging van een ernstig beveiligingsincident hangt nog altijd als het zwaard van Damocles boven het internet.
We weten dat achter iedere website, webshop of applicatie een organisatie zit die ervan afhankelijk is. Soms betekent een uur onbereikbaarheid omzetverlies. Soms kunnen medewerkers hun werk niet doen. En soms zijn belangrijke diensten tijdelijk niet beschikbaar.
Het alternatief is een mogelijk ernstig beveiligingsincident, waarvan niemand de gevolgen kunnen overzien. Inmiddels hebben ook grote organisaties besloten hun dienstverlening uit voorzorg offline te halen.
De maatregelen van vanochtend kúnnen het risico hebben verkleind, maar zekerheid bestaat niet zolang de officiële details ontbreken. En met nog iets meer dan een uur tot de bekendmaking is het simpelweg onverantwoord om de websites en applicaties nog online te houden.
Om 15:15 uur gaan alle Core-omgevingen offline, met een melding vooraf. Bezoekers krijgen een informatiepagina te zien waarin we uitleggen waarom de website of applicatie tijdelijk onbereikbaar is.
16:00 uur. Het moment waar alles om draait
De technische details van de twee kwetsbaarheden worden - rond 15:45 al - openbaar gemaakt.
Het blijkt inderdaad om ernstige beveiligingsproblemen te gaan. Onder bepaalde omstandigheden kunnen aanvallers op afstand code uitvoeren op een kwetsbare PHP-installatie, zonder daarvoor ingelogd te hoeven zijn.
Onze engineers beoordelen de informatie, controleren de beschikbaarheid van de nieuwe PHP-versies en bereiden de uitrol voor.
Om 16:20 uur beginnen we met het installeren van de beveiligingsupdates op Cyberfusion Core.
De omgevingen komen stapsgewijs weer online zodra de noodzakelijke updates zijn geïnstalleerd en we voldoende zekerheid hebben dat ze veilig bereikbaar kunnen worden gemaakt.
Om 17:35 uur kunnen we melden dat veel omgevingen alweer online zijn. De rest volgt kort daarna.
Om 18:06 uur zijn alle klantsites -en applicaties bijgewerkt en weer bereikbaar.
Achter de schermen werken we verder. We draaien de tijdelijke beveiligingsmaatregelen van eerder die dag - waar nodig - terug en blijven controleren of alles naar behoren functioneert.
De meerwaarde van managed hosting
Managed hosting is een breed begrip. Wat een hostingprovider precies beheert en welke verantwoordelijkheden bij de klant blijven liggen, verschilt per aanbieder.
Soms krijg je een VPS waarop de leverancier het besturingssysteem onderhoudt. Soms worden ook de webserver, database en PHP-configuratie beheerd. En soms omvat de dienstverlening ook proactieve beveiligingsmaatregelen, monitoring en incidentrespons.
Die verschillen zijn op een gewone dag niet altijd zichtbaar. Op een dag als 21 oktober - waar er nog meer van gaan komen - wel.
Wie volgt beveiligingsmeldingen? Wie beoordeelt de risico’s? Wie bepaalt of een omgeving tijdelijk offline moet? Wie voert de noodzakelijke wijzigingen uit? En wie informeert de klanten?
Die vragen moet je als webbureau, SaaS-bedrijf of ontwikkelaar van een groot platform kunnen beantwoorden.
Bedankt voor het vertrouwen
In de uren en dagen na het incident ontvingen we veel positieve reacties van klanten. Vooral over de snelheid waarmee we hadden gehandeld, en hoe uitgebreid we gedurende de dag -continu- hebben gecommuniceerd.
En dan zet je in Zwitserland de televisie aan...
Een dag later zit ik op mijn hotelkamer in Zwitserland. Ik zet de televisie aan en zie PHP alweer voorbijkomen.
Ergens is het totaal bizar. Bijna 70% van alle websites waarvan we de server-side programmeertaal kennen, draait op PHP. En daarmee is een enorm deel van het internet afhankelijk van een kleine groep ontwikkelaars, van wie een deel dit werk vrijwillig doet.
Als er iets ernstigs misgaat, hoor je erover van hier tot Tokio. Of in dit geval, Zwitserland.
De PHP Foundation ontving in 2025 ongeveer 730.000 dollar aan donaties. Daarmee worden onder andere ontwikkelaars betaald die PHP onderhouden en verbeteren.
Veel geld? Nee. Bedenk hoeveel bedrijven, overheden en organisaties wereldwijd afhankelijk zijn van hun werk.
Ik zag op LinkedIn allerlei hostingproviders vertellen hoe snel ze hun PHP-omgevingen hadden bijgewerkt. Wij ook. En terecht: dankzij snel en zorgvuldig handelen kunnen klanten veilig verder.
Maar laten we vooral niet vergeten waarom we die updates überhaupt konden installeren. Er zijn mensen die zich dag in, dag uit bezighouden met het onderhouden, verbeteren en beveiligen van PHP. Mensen die ervoor zorgen dat er, wanneer het écht nodig is, beveiligingsupdates klaarliggen waar de rest van de wereld mee aan de slag kan.
Dus ja: bedank vooral je systeembeheerders en hostingprovider als ze snel hebben gehandeld. Maar vergeet ook de mensen niet die ervoor hebben gezorgd dat die beveiligingsupdates überhaupt beschikbaar waren: de ontwikkelaars achter PHP.
En belangrijker nog: geef ze geld.
Als je bedrijf afhankelijk is van PHP, is een financiële bijdrage aan het onderhoud ervan eigenlijk het minste wat je kunt doen.
Twee mooie initiatieven:
- The PHP Foundation ondersteunt en betaalt ontwikkelaars die PHP onderhouden en verbeteren.
- Ondřej Surý verzorgt al jarenlang PHP-packages voor Debian en Ubuntu, waar talloze hostingomgevingen op vertrouwen.
We verdienen allemaal geld dankzij het werk van deze mensen. Daar mag best wat tegenover staan.
Hoe is jullie hosting geregeld?
De PHP-kwetsbaarheden van 21 oktober waren uitzonderlijk. Waren, want dit gaat vaker voorkomen.
Of je nu zelf een VPS beheert, als webbureau websites voor klanten host of een SaaS-platform ontwikkelt: het is verstandig om te weten wie de beveiliging en het onderhoud van je infrastructuur verzorgt. En vooral wat er gebeurt wanneer snel ingrijpen noodzakelijk is.
Heeft 21 oktober je aan het denken gezet over je eigen hostingsituatie? We wisselen graag van gedachten.
