Op 20 oktober 2026 waarschuwde het PHP-team voor twee kritieke lekken in PHP. Een dag later lag de oplossing klaar. Toch was niet elke website even snel veilig. Het verschil zat niet in de website zelf, maar in de vraag wie de server eronder beheert. In dit artikel leggen we uit wat er aan de hand was en welke vragen je als ondernemer aan je IT-partij of hostingbedrijf kunt stellen.
Wat was er aan de hand?
PHP is de programmeertaal waar een groot deel van alle websites op draait, waaronder vrijwel alle WordPress-sites. In oktober werden twee ernstige lekken in PHP zelf bekend. Onder de naam PHP2Shell kregen ze een risicoscore van 9,2 op een schaal van 10. Via deze lekken kon een aanvaller onder bepaalde omstandigheden zonder in te loggen eigen code uitvoeren op de server van een website.
Het PHP-team kondigde de spoedupdate aan op 20 oktober. Omdat details al eerder uitlekten, kwam de update een dag eerder dan gepland, op 21 oktober. Beveiligingsbedrijven meldden in die uren al de eerste aanvalspogingen.
De veilige versies zijn PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Voor PHP 8.1 en ouder is geen gewone update verschenen, omdat die versies niet meer worden onderhouden.
Belangrijk om te weten. Het lek zat niet in WordPress of een plug-in, maar in de software op de server. Je website updaten loste het dus niet op. Ook een site die verder keurig is bijgehouden, bleef kwetsbaar zolang PHP op de server niet was bijgewerkt.
Twee ondernemers, dezelfde woensdag
Stel je twee ondernemers voor met allebei een WordPress-website. Een verzonnen voorbeeld, maar wel gebaseerd op hoe het in de praktijk liep.
Sanne heeft een webshop bij een grote hostingpartij met beheerde hosting. De hostingpartij beheert de servers en dus ook PHP. Op 21 oktober krijgt ze een bericht dat er gewerkt wordt aan een beveiligingsupdate. Bij sommige partijen gaat haar site een paar uur uit de lucht als voorzorg. Dezelfde dag of de dag erna staat de update erop. Sanne hoeft zelf niets te doen.
Mark heeft zijn website bij de lokale IT-partner die ook zijn computers en netwerk regelt. Die partner heeft de site op een eigen of gehuurde server gezet. Wie PHP op die server bijwerkt, staat niet zwart op wit. Mark neemt aan dat het onderhoudscontract dit dekt. Of en wanneer de update erop staat, hangt af van de vraag of zijn IT-partner het nieuws heeft gezien, er die dag tijd voor heeft en weet hoe het moet. Draait de server nog op een oude PHP-versie, dan is er geen kant-en-klare update en wordt het nog lastiger.
Geen van beide situaties is per definitie goed of fout. Veel lokale IT-partners hebben dit prima geregeld. Maar bij Mark is het minder vanzelfsprekend, en hij weet het niet zeker.
Het verschil zit in wie de server beheert
Grote hostingpartijen met beheerde hosting kunnen zo’n update centraal uitrollen over al hun servers. Veel van hen hadden PHP binnen een dag bijgewerkt. Sommigen haalden websites daarvoor tijdelijk offline. Dat is vervelend, maar wel een bewuste keuze om klanten te beschermen.
Ook bij grote partijen gold een uitzondering. Wie daar een eigen virtuele server (VPS) of losse server huurt, moest PHP vaak zelf bijwerken of laten bijwerken. Groot of klein is dus niet de kern. De kern is of iemand verantwoordelijk is voor PHP op jouw server, en of dat ook echt gebeurt.
Bij een lokale IT-partner is die verantwoordelijkheid vaak minder duidelijk vastgelegd. Een onderhoudscontract voor je website betekent niet automatisch dat ook de server eronder wordt bijgewerkt. Juist dat gat werd met PHP2Shell zichtbaar.
Vragen om te stellen aan je lokale IT-aanbieder
Weet je niet precies hoe het bij jou geregeld is? Stel je IT-aanbieder of hostingpartij deze vragen. Een goede partij beantwoordt ze zonder moeite.
Wie is verantwoordelijk?
- Waar draait mijn website precies? Bij een hostingpartij, op een eigen server van jullie, of op een gehuurde server?
- Wie werkt PHP en de rest van de serversoftware bij? Jullie, de hostingpartij of ik zelf?
- Staat dat in ons contract, en valt het onder het onderhoud dat ik nu betaal?
Hoe zit het met updates?
- Op welke PHP-versie draait mijn website nu?
- Is die versie nog ondersteund, en tot wanneer?
- Hoe snel voeren jullie een kritieke beveiligingsupdate door? Binnen een dag, een week of langer?
- Hoe houden jullie bij dat er een nieuw lek is? Volgen jullie bijvoorbeeld de waarschuwingen van het NCSC?
Wat als het misgaat?
- Hoe hebben jullie PHP2Shell aangepakt, en wanneer stond de update op mijn server?
- Krijg ik een bericht als er een ernstig lek speelt, ook als jullie het al hebben opgelost?
- Wie is er bereikbaar als het buiten kantoortijd of in de vakantie gebeurt?
- Worden er back-ups gemaakt, staat er minstens één los van de server, en wordt terugzetten af en toe getest?
Vooruitkijken
- PHP 8.2 wordt na 31 december 2026 niet meer onderhouden. Draait mijn site daarop, en wanneer stappen jullie over naar een nieuwere versie?
- Is het slimmer om mijn website onder te brengen bij beheerde hosting, waar de serverupdates centraal geregeld worden?
Vraag de antwoorden bij voorkeur op papier of per mail. Dan weet je precies wat je kunt verwachten en kun je er later op terugvallen.
PHP2Shell is inmiddels opgelost voor wie de update heeft gekregen. Maar het volgende lek komt er zeker aan. Wie nu weet hoe het bij zijn eigen website geregeld is, hoeft dan niet te gokken.
