PHP2Shell: waarom onze klanten online bleven tijdens een grote beveiligingscrisis

Op woensdag 21 oktober 2026 werd een groot deel van de internetwereld opgeschrikt door twee kritieke beveiligingskwetsbaarheden in PHP. Websites van onder andere overheidsinstanties werden uit voorzorg offline gehaald. Ook het Nationaal Cyber Security Centrum (NCSC) schakelde zijn eigen website tijdelijk uit.

De kwetsbaarheden, gezamenlijk bekend als PHP2Shell, maakten het mogelijk dat aanvallers onder bepaalde omstandigheden op afstand kwaadaardige code konden uitvoeren op kwetsbare servers.

Bij Brightness Group kwamen we direct in actie. Nog vóór 12:00 uur hadden we eigen tijdelijke beveiligingsmaatregelen uitgerold. Om 16:15 uur was de officiële beveiligingspatch bij al onze betrokken klanten geïnstalleerd.

Het resultaat? Onze klantwebsites bleven online, zonder downtime.

Maar wat ging er technisch precies mis? En hoe konden wij onze dienstverlening beschikbaar houden terwijl andere organisaties hun websites moesten uitschakelen?

Wat is PHP en waarom was dit beveiligingslek zo ernstig?

PHP is een programmeertaal die wereldwijd wordt gebruikt voor websites, webshops en zakelijke applicaties.

Bekende systemen zoals WordPress, WooCommerce, Drupal en Laravel draaien op PHP. Het vormt daarmee een belangrijk onderdeel van de technische infrastructuur achter miljoenen websites. De kwetsbaarheden van 21 oktober zaten niet in een specifieke website of plug-in, maar in de PHP-runtime zelf: de software die PHP-code op een server uitvoert. Dat maakte de situatie uitzonderlijk ernstig. Zelfs een website met volledig bijgewerkte plug-ins en veilig geschreven applicatiecode kon kwetsbaar zijn wanneer de onderliggende PHP-versie niet was bijgewerkt.

Hoe ontstond PHP2Shell?

De problemen kwamen voort uit fouten in het geheugenbeheer van PHP. Wanneer een webserver een verzoek ontvangt, reserveert PHP tijdelijk werkgeheugen om gegevens te verwerken. Na afloop moet dit geheugen correct worden vrijgegeven en moeten interne verwijzingen worden opgeschoond. Onder bepaalde omstandigheden verliep dat proces niet goed.

Bijvoorbeeld wanneer PHP tijdens het verwerken van een verzoek onvoldoende geheugen beschikbaar had of onverwacht moest stoppen. Hierdoor konden interne verwijzingen naar eerder gebruikte geheugengebieden blijven bestaan. In de beveiligingswereld wordt dit onder andere een use-after-free-probleem genoemd. Een aanvaller kon dergelijke fouten onder specifieke omstandigheden misbruiken om geheugeninhoud te benaderen, gegevens te manipuleren of uiteindelijk eigen code uit te voeren.

Twee kritieke kwetsbaarheden

De beveiligingsproblemen kregen twee officiële registratienummers:

CVE-2026-109618: Fout bij onvoldoende geheugen

• Deze kwetsbaarheid ontstond wanneer PHP tijdens bepaalde bewerkingen onvoldoende geheugen beschikbaar had.

• Door een fout in de afhandeling van deze situatie konden interne gegevens onvolledig worden geïnitialiseerd.

• Bij het opruimen van het verzoek kon PHP vervolgens proberen deze ongeldige gegevens toch te verwerken.

• Dat kon leiden tot geheugenbeschadiging en uiteindelijk het uitvoeren van ongeautoriseerde code.
  

CVE-2026-109619: Verouderde geheugenverwijzingen

De tweede kwetsbaarheid had betrekking op interne gegevens die na afloop van een verzoek niet altijd correct werden opgeschoond. Een volgend verzoek kon daardoor verwijzingen gebruiken naar geheugen dat inmiddels was vrijgegeven.

Dit creëerde mogelijkheden voor aanvallers om het geheugenproces te manipuleren en onder bepaalde omstandigheden code op de server uit te voeren. Beide kwetsbaarheden kregen een kritieke beveiligingsscore van 9,2 op de CVSS 4.0-schaal.

Wat konden hackers hiermee doen?

Het grootste risico was zogenaamde Remote Code Execution (RCE).

Dat betekent dat een aanvaller via het internet code kan uitvoeren op een kwetsbare server, zonder daarvoor eerst te hoeven inloggen.

Afhankelijk van de serverconfiguratie en de rechten van het PHP-proces konden de gevolgen ernstig zijn:

• Toegang krijgen tot vertrouwelijke gegevens.

• Gevoelige informatie zoals tokens of API-sleutels uit het geheugen

• Gevoelige informatie zoals tokens of API-sleutels uit het geheugen uitlezen.

• Kwaadaardige code uitvoeren binnen de rechten van het PHP-proces.

• Websites of applicaties manipuleren.

• De beschikbaarheid en integriteit van systemen aantasten.

Bijzonder was dat de kwetsbaarheden al tijdens de verwerking van webverzoeken konden worden misbruikt, voordat de eigenlijke applicatiecode werd uitgevoerd.

Hierdoor waren traditionele beveiligingsmaatregelen binnen een applicatie niet altijd voldoende.

Waarom speelde het uploaden van bestanden een rol?

• Een van de bekende aanvalsroutes had betrekking op de verwerking van bestandsuploads.

• Wanneer een bezoeker een bestand uploadt, verwerkt PHP gegevens over het bestand en eventueel de voortgang van de upload.

• Bij deze verwerking worden tijdelijk gegevens in het geheugen opgeslagen.

• Onder specifieke omstandigheden konden fouten in het geheugenbeheer worden uitgelokt via speciaal samengestelde HTTP-verzoeken, waaronder multipart/form-data-verzoeken.

• Daarom richtten verschillende tijdelijke beveiligingsmaatregelen zich op onderdelen van de uploadverwerking.

• Het beperken of uitschakelen van uploadfunctionaliteit kon bepaalde aanvalsroutes verminderen, maar was geen volledige oplossing voor beide kwetsbaarheden.

• De definitieve beveiligingsupdate was noodzakelijk om het probleem in de PHP-runtime zelf te verhelpen.

Waarom gingen zoveel websites offline?

Omdat de kwetsbaarheden in PHP zelf zaten, waren veel verschillende soorten websites en applicaties mogelijk getroffen. Bovendien kwamen technische details over de beveiligingsproblemen voortijdig naar buiten. Hierdoor ontstond extra tijdsdruk voor hostingproviders, systeembeheerders en beveiligingsteams. De officiële beveiligingsupdates waren op dat moment nog niet beschikbaar. Organisaties moesten daarom een afweging maken tussen beschikbaarheid en beveiliging. Verschillende partijen besloten hun websites tijdelijk offline te halen om mogelijke aanvallen te voorkomen. Het NCSC adviseerde organisaties om kwetsbare systemen zo snel mogelijk bij te werken en benadrukte dat tijdelijke maatregelen geen volledige bescherming boden.

Hoe Brightness Group reageerde

Bij Brightness Group hebben we direct gehandeld om de risico's voor onze klanten te beperken. Onze aanpak bestond uit drie belangrijke stappen.

1. Vóór 12:00 uur: eigen tijdelijke beveiligingsmaatregelen

Ons technische team had nog vóór het middaguur tijdelijke beveiligingsmaatregelen ontwikkeld en uitgerold op onze servers. Hiermee beperkten we direct de blootstelling aan bekende aanvalsroutes. Als gevolg hiervan kon het uploaden van bestanden tijdelijk beperkt functioneren. We kozen bewust voor maatregelen waarmee we risico's konden verminderen zonder alle klantwebsites volledig offline te halen.

2. Voorbereiding op de officiële beveiligingspatch

Terwijl we de situatie nauwlettend volgden, bereidden onze ontwikkelaars en systeembeheerders scripts voor om de officiële beveiligingsupdates zo snel mogelijk te kunnen installeren. Dit was een belangrijk onderdeel van onze aanpak. Door vooraf de uitrol voor te bereiden, konden we de tijd tussen het beschikbaar komen van de beveiligingspatch en de daadwerkelijke installatie aanzienlijk beperken.

3. Om 16:15 uur: officiële patch volledig uitgerold

Zodra de officiële beveiligingsupdates beschikbaar kwamen, konden we direct handelen. Om 16:15 uur waren alle betrokken klantomgevingen voorzien van de officiële beveiligingspatch. De tijdelijke beperkingen konden vervolgens worden opgeheven en de normale functionaliteit worden hersteld. Gedurende het hele incident bleven de websites van onze klanten bereikbaar. Het resultaat: geen downtime en minimale overlast. Dankzij de combinatie van technische kennis, proactief handelen en automatisering konden we de impact van het incident voor onze klanten beperken.

Onze resultaten:

• Vóór 12:00 uur: tijdelijke beveiligingsmaatregelen actief.

• 16:15 uur: officiële beveiligingspatch volledig uitgerold.

• Geen downtime: klantwebsites bleven online.

• Proactieve communicatie: meldingen via onze website en klantomgeving.

• Minimale supportbelasting: ongeveer tien telefoontjes en enkele berichten.

Voor onze klanten betekende dit dat hun websites en applicaties beschikbaar bleven tijdens een groot beveiligingsincident.

Waarom goede hosting meer is dan een server aanbieden

Dit incident laat zien dat professioneel hostingbeheer veel verder gaat dan alleen het beschikbaar stellen van servercapaciteit. Het vereist technische kennis, actieve monitoring, automatisering en vooral de mogelijkheid om snel beslissingen te nemen. Bij Brightness Group combineren we softwareontwikkeling, serverbeheer en hosting binnen één organisatie. Daardoor kunnen we niet alleen beveiligingsupdates installeren, maar ook zelf tijdelijke technische oplossingen ontwikkelen en implementeren wanneer de situatie daarom vraagt. Die combinatie maakt het mogelijk om sneller te reageren op onverwachte beveiligingsproblemen.

Wat kunnen bedrijven hiervan leren?

De PHP2Shell-kwetsbaarheden laten zien hoe afhankelijk moderne organisaties zijn van de beveiliging van hun onderliggende software. Zelfs wanneer een website technisch goed is gebouwd, kunnen kwetsbaarheden in frameworks, programmeertalen of servercomponenten grote gevolgen hebben. Daarom zijn structureel onderhoud, tijdige updates, monitoring en een goed incidentresponsproces essentieel. Tijdelijke beveiligingsmaatregelen kunnen helpen om risico's te beperken, maar vervangen nooit een definitieve beveiligingsupdate.

De belangrijkste les: beveiliging begint niet op het moment dat er iets misgaat. Het begint bij de voorbereiding daarop.

Conclusie: waarom bij ons de stekker er niet uit hoefde

Terwijl verschillende organisaties hun websites tijdelijk uitschakelden, konden wij onze klanten online houden. Niet omdat de kwetsbaarheden voor onze systemen irrelevant waren, maar omdat ons team snel reageerde, tijdelijke maatregelen implementeerde en de definitieve beveiligingspatch vrijwel direct kon uitrollen. We zijn trots op de inzet van onze ontwikkelaars en systeembeheerders. Dit incident onderstreept waar wij bij Brightness Group voor staan:

Proactief beheer. Technische expertise. Maximale continuïteit.