Het PHP-lek van 21 oktober: wie keek er naar jouw website?

Woensdag 21 oktober ging DigiD uit de lucht. MijnOverheid ook, net als de websites van de Tweede Kamer, RTL Nieuws en Tweakers (NOS, 21 oktober 2026). De oorzaak was het PHP-lek: twee kritieke fouten in de programmeertaal waar zo'n 70 procent van alle websites op draait. Bij Your Tech Club draaien meerdere klantprojecten op PHP. Die woensdag hebben we ze één voor één bekeken: wat is hier het risico, en wat wil de klant zelf?

Inmiddels is de update er en lijkt de rust terug. Toch blijft er één vraag liggen die ik deze week vaker hoorde dan "ben ik veilig?". Die vraag is: wie had er eigenlijk dienst?

Wat is het PHP-lek van oktober 2026 precies?

Het PHP-lek bestaat uit twee kritieke kwetsbaarheden in PHP zelf, bekend als CVE-2026-109618 en CVE-2026-109619, of kortweg PHP2Shell. Een aanvaller kan er zonder in te loggen code mee uitvoeren op je webserver. PHP bracht de oplossing uit op 21 oktober rond 16.00 uur: versie 8.5.12, 8.4.27, 8.3.36 en 8.2.35.

De fouten kregen een ernstscore van 9,2 op 10. Volgens Sansec zitten ze in elke PHP-versie sinds 5.4, dus al ruim tien jaar. Daarom haalden organisaties hun sites uit voorzorg offline, nog voordat de update er was.

Eén ding is bij veel ondernemers nog niet helemaal geland. Het lek zat niet in WordPress, niet in je thema en niet in een plugin. Het zat in de software op de server. Een WordPress-update loste dus niets op. Alleen een nieuwe PHP-versie op de server deed dat.

Hoe werd het PHP-lek ontdekt?

Door AI. Beveiligingsbedrijf Calif vond het eerste lek met GPT-5.6 Sol van OpenAI en meldde het op 11 augustus bij PHP. Wiz vond beide fouten los daarvan, onder meer met Gemini 4 Argon van Google. De bekendmaking stond gepland voor 22 oktober, maar de informatie lekte eerder uit.

Dit vind ik het belangrijkste deel van het verhaal. De fouten stonden ruim tien jaar in de code zonder dat iemand ze zag. Met AI vonden onderzoekers ze binnen een paar weken. Wiz zegt zelfs dat één onderzoeker in een week deed waar een topteam vroeger maanden over deed. Die claim komt van een bedrijf dat beveiligingssoftware verkoopt. De richting klopt wel.

Ook aanvallers gebruiken AI. Een hacker met de naam KillaBoi kraakte vorige week een testserver via het lek en won daarmee zo'n 2.000 dollar aan bitcoin. Volgens BNR had hij er bijna 20 uur, veel vakkennis én AI voor nodig.

Lekken worden dus sneller gevonden, en door beide kanten. OpenAI, dat meehielp aan de ontdekking, verwacht zelf dat zulke vondsten de komende maanden flink toenemen. Wat AI nog meer kan, lees je in mijn stuk over GPT-6.1 Terra. Voor websitebeheer betekent het vooral dat je per site moet weten wat er draait en wie erover beslist. Dat is geen IT-detail meer.

Moet ik nu nog iets doen aan het PHP-lek?

Ja, tenzij je zeker weet dat de update op jouw server staat. Vraag je hoster of bureau welke PHP-versie je website draait en of die op of na 21 oktober is bijgewerkt. Draait je site op PHP 8.1 of ouder, plan dan een upgrade. Die versies krijgen van PHP zelf geen gewone updates meer.

Loop deze punten na, of laat je bureau het doen:

1. Vraag je PHP-versie op. In WordPress vind je die onder Sitediagnose, bij de serverinformatie.
2. Check de datum. Staat de build date in phpinfo op 21 oktober 2026 of later, dan is de patch er.
3. Kijk vooruit. PHP 8.2 krijgt na 31 december 2026 geen beveiligingsupdates meer. Plan de overstap naar 8.3 of 8.4 nu al.
4. Installeer geen fix-plugins. Een plugin kan een lek in PHP zelf niet dichten, en zulke codesnippets kunnen je site juist breken.
5. Vraag of iemand in de logs heeft gekeken. Amazon zag de eerste aanvalspogingen al op 17 oktober, vier dagen vóór de bekendmaking.

Over dat laatste punt is er ook goed nieuws. Sansec voorspelde eerst grootschalig misbruik binnen een kwartier na de update. Een dag later stelde het bedrijf dat bij, want de openbare aanvalsscripts werken niet tegen een standaard PHP-installatie. Het NCSC zei op 23 oktober hetzelfde: de kans op grootschalig misbruik is kleiner dan gedacht. Klein is alleen niet nul.

Wie is verantwoordelijk als je website lek is?

Jij, als eigenaar van de website. Het werk ligt in de praktijk wel bij meerdere partijen. Je hoster patcht de server, je bureau beheert de code en de koppelingen, en jij beslist wie je belt als het misgaat. Bij gedeelde hosting deed de hoster deze keer het meeste werk. Had je een eigen server, dan lag het bij jou.

Hostingpartijen als Versio en Yourhosting dichtten het lek centraal op hun servers. Klanten met gedeelde hosting hoefden daar zelf niets voor te doen. Veel bedrijfswebsites draaien echter niet op gedeelde hosting. Ze staan op een eigen server, een VPS of bij een cloudpartij, en daar patcht niemand automatisch.

Bij ons liepen de vragen die dag flink uiteen. Een aantal grotere projecten ging offline tot de update er was; dat was een bewuste keuze, samen met de klant. Andere bleven online, met de risico's in beeld. Uiteindelijk hebben we alles veilig kunnen houden.

Daar zit mijn punt. Een website zonder onderhoudsafspraak is geen besparing, het is een gok. Meestal gaat die gok goed. Op 21 oktober ging hij voor veel bedrijven bijna mis.

Wat moet er in een onderhoudscontract voor je website staan?

Minimaal vier dingen: wie de server en de PHP-versie bijhoudt, binnen hoeveel uur iemand een kritiek lek dicht, hoe je daarover hoort en waar een back-up staat die los van je server is opgeslagen. Een reactietijd alleen zegt weinig. Je wilt een belofte over het dichten, niet alleen over het terugbellen.

Wat ik níet zou doen: je website uit paniek naar een ander platform verhuizen. Een site in Next.js of een Shopify-winkel draait niet op een eigen PHP-server, dus dit lek raakte die niet direct. Maar elk platform heeft zijn eigen lekken. Kies op beheer, niet op het nieuws van vorige week.

Hoe wij dat regelen? Niet met één tool. Onze beheerklanten hebben een SLA, en daaronder draaien meerdere monitortools. Externe diensten sturen een melding zodra er iets afwijkt. Daarnaast houden we het nieuws over lekken bij en kijken we naar ongewone activiteit op de sites. Die bronnen komen samen, en klanten zien het in hun eigen dashboard. Is iets kritiek, dan krijgt de juiste persoon direct een melding op mobiel of per sms, afhankelijk van de SLA. Een website-agent is daar één onderdeel van, geen vervanging.

Hoe weet je of jouw website goed geregeld is?

Het volgende lek komt. Dat zeg ik niet om je bang te maken; OpenAI en Wiz zeggen het zelf. De vraag is alleen of je dan binnen een uur weet wie er aan de slag gaat.