In dit artikel
Wat er op 21 oktober gebeurde
Woensdag 21 oktober 2026, rond één uur ‘s middags, gingen in Nederland de eerste websites uit de lucht. De Tweede Kamer, MijnOverheid, DigiD, dertien van de 25 veiligheidsregio’s, ziekenhuizen, RTL Nieuws. Niet omdat ze gehackt waren, maar uit voorzorg.
De reden: twee kritieke lekken in PHP, de programmeertaal achter bijna 70 procent van de websites, van WordPress tot webshops. Via die lekken kon een aanvaller van buitenaf een server overnemen, zonder wachtwoord. Onderzoekers noemden het PHP2Shell. Officieel heten de lekken CVE-2026-109618 en CVE-2026-109619.
Rond vier uur bracht PHP de reparatie uit. Wie wist wat er draaide en wie er aan de knop zat, kon dezelfde avond weer online. MijnOverheid was even na zevenen terug.
Waarom een WordPress-update hier niet hielp
De meeste beveiligingslekken zitten in een plugin of een los onderdeel. Dit lek zat in PHP zelf. Vergelijk het met een scheur in de fundering in plaats van in een raam: alles wat erop staat, loopt risico. De website, de webshop, het klantportaal, het interne systeem waar je orders doorheen gaan.
Het oudste deel van de scheur zat er volgens de ontdekkers al sinds PHP 5.4, uit 2012. Daarom raakte het lek bijna elke PHP-versie die vandaag nog ergens draait.
En er was geen omweg. PHP gaf wel tijdelijke instellingen, maar zei er zelf bij dat die een installatie niet veilig maken. Bijwerken was de enige echte oplossing.
Gevonden met AI
Veertien jaar zag niemand de scheur als echt gevaar. In 2020 meldde iemand een fout die onschuldig leek, en bij een controle van PHP in 2024 kwam hetzelfde probleem weer boven. Niemand bewees toen dat je er een server mee kon overnemen. Dit jaar lukte dat wel, met AI. Het Amerikaanse securitybedrijf Calif vond een van de twee lekken in augustus met GPT-5.6 Sol, een AI-model van OpenAI. Dat gebeurde binnen Patch the Planet, een programma van OpenAI om lekken in veelgebruikte software te vinden voordat aanvallers dat doen. Het securitybedrijf Wiz vond beide lekken los daarvan, ook met hulp van AI.
De AI deed het niet alleen. De onderzoeker van Calif koos zelf waar hij zocht en had al het vermoeden dat er oude fouten in PHP zaten. De AI vond daarna de route naar de fout in de code. Calif schrijft zelf dat geen model met een simpele opdracht alle lekken vindt.
Opvallend is wat Calif gebruikte: geen geheime modellen, maar AI die voor iedereen beschikbaar is. Dus ook voor aanvallers. Na de bekendmaking bracht OpenAI een PHP-versiecheck uit als skill voor Codex, zijn AI-tool voor ontwikkelaars.
Wat het betekent als jouw bedrijf op PHP draait
Weet je niet of je op PHP draait? Gebruik je WordPress, WooCommerce, Magento, Drupal of Joomla, dan is het antwoord ja. Is je software op maat gebouwd, vraag het je ontwikkelaar.
Draai je op PHP, dan hangt alles af van één vraag: welke versie?
| Jouw PHP-versie | Wat er op 21 oktober klaarlag | Wat je nu doet |
|---|---|---|
| 8.3, 8.4 of 8.5 | Een officiële update | Bijwerken naar 8.3.36, 8.4.27 of 8.5.12 en PHP opnieuw opstarten |
| 8.2 | Een officiële update, maar de ondersteuning stopt op 31 december 2026 | Bijwerken naar 8.2.35 en de overstap naar 8.3 of hoger inplannen |
| 7.4, 8.0 of 8.1 | Alleen een reparatie in de broncode, geen kant-en-klare update | Laten inbouwen door je ontwikkelaar en de upgrade inplannen |
| 7.3 of ouder | Niets | Van internet halen tot er een plan ligt |
Test na het bijwerken of alles nog werkt. Bij een deel van de applicaties op 8.4 en 8.5 veroorzaakte de update zelf een nieuwe fout.
Vier vragen voor je hoster of ontwikkelaar, ook als die zegt dat het geregeld is:
- Welke versie draaien we? Gebruik je WordPress, dan zie je het zelf onder Hulpmiddelen, Sitediagnose, Info, Server. Vergelijk het met de ondersteunde versies van PHP.
- Is PHP na de update opnieuw opgestart? Een update werkt pas als de draaiende PHP-processen opnieuw starten. Tot die tijd draait de oude, lekke versie gewoon door.
- Is er al eerder iets gebeurd? Amazon zag de eerste aanvalspoging al op 17 oktober, vier dagen voor de update. Inmiddels staan beide lekken op de lijst van actief misbruikte kwetsbaarheden van de Amerikaanse cyberdienst CISA. Een update dicht het lek, maar haalt geen indringer weg die al binnen zat. Laat de server controleren op onbekende bestanden en accounts.
- Waar zit PHP nog meer? Niet alleen in je website. Ook in software van leveranciers en in apparatuur zoals firewalls en netwerkopslag. Vraag je leveranciers of hun producten zijn bijgewerkt.
Zes lessen, ook als je niet op PHP draait
Wij bouwen maatwerk software voor onze klanten, maar niet in PHP. Dit lek raakte hun software dus niet. Toch is de les voor ons net zo groot. Elke programmeertaal, ook die waarin wij bouwen, werkt volgens dezelfde regel: een versie krijgt een einddatum, en daarna sta je er alleen voor.
1. Je risico zit niet in de taal, maar in stilstand
PHP leverde de reparatie dezelfde middag. Het verschil tussen een rustige avond en een probleem zat dus niet bij PHP, maar bij hoe bedrijven hun software bijhielden. Wie bijhield, draaide één update. Wie al jaren op een oude versie zat, had geen update om te draaien.
2. Weet wie er aan de knop zit
Wist jij op 21 oktober meteen wie je moest bellen? En wist diegene wat er op jouw server draaide? Dat regel je niet tijdens een lek, maar ervoor. Leg in een SLA of onderhoudscontract vast wie er reageert als er een lek bekend wordt, en hoe snel.
3. Weet wat er draait
Je kunt niets bijwerken waarvan je niet weet dat het er is. Zet op één A4 welke systemen je hebt, op welke versie ze draaien en wie ze onderhoudt. Dat is een middag werk. Bij het volgende lek scheelt die lijst je uren.
Bij de software die wij bouwen, hangt dat niet van iemands geheugen af. We krijgen automatisch een melding zodra een onderdeel waar die software op draait verouderd is of een bekend lek heeft.
4. Uitstellen is ook een keuze
PHP 8.1 kreeg al geen beveiligingsupdates meer. Wie de overstap had uitgesteld, betaalde daar op 21 oktober de prijs voor. Die rekening komt niet op het moment dat jij kiest, maar op het moment dat een lek bekend wordt. Draai je op PHP 8.2? Dan sta je op 1 januari 2027 in dezelfde positie.
5. AI versnelt beide kanten
Lekken die jaren verborgen bleven, vind je met AI nu in weken. Dat geldt voor onderzoekers, en net zo goed voor aanvallers. Software die niemand bijhoudt, wordt daardoor elk jaar kwetsbaarder.
Wij zien daar vooral een kans in. Dezelfde snelheid werkt ook voor wie bouwt en bijhoudt. Software die wél wordt bijgehouden, wordt met AI elk jaar sterker.
“Dit lek zat veertien jaar in PHP zonder dat iemand het als gevaar zag. Met AI erbij had een onderzoeker in ruim twee weken een werkende aanval. Dat tempo kan nu iedereen halen, ook een aanvaller. Daarom kijkt bij ons bij elk project AI mee naar de code, en blijft een ontwikkelaar eindverantwoordelijk. De vraag is niet meer óf er een lek in software zit, maar wie het als eerste vindt.”
Davey Cornelissen, Co-Owner & Lead Software bij Retrii
6. Kies een leverancier die verder kijkt dan de opdracht
Er zijn twee soorten softwareleveranciers. De codeklopper bouwt wat je vraagt, levert op en is weg. De andere blijft naast je staan nadat je software live staat. Dat verschil zie je niet bij de oplevering. Je ziet het op de dag dat er een lek bekend wordt.
Wie naast je staat, herken je aan gedrag, niet aan beloftes:
- Je hoort het van hen, niet uit het nieuws. Zit er een lek in iets waar jouw software op draait, dan bellen ze jou voordat jij hen belt.
- Ze kijken vooruit. Ze zeggen het als een versie richting haar einddatum gaat en plannen de overstap voordat de ondersteuning stopt.
- Ze zijn kritisch, ook ongevraagd. Ze wijzen op wat beter kan, ook als het niet in de opdracht stond.
- Ze bewegen mee. Ze volgen wat er verandert in de softwarewereld, zoals AI, en vertellen wat dat voor jouw software betekent. Verandert een systeem waar je software mee praat, dan houden ze de API-koppeling werkend.
Twijfel je? Stel je leverancier één vraag: wanneer hebben jullie ons voor het laatst zelf gebeld over iets waar wij niet om vroegen? Duurt het antwoord lang, dan weet je genoeg. Zo’n leverancier houdt je software niet alleen bij, maar laat ook zien wat er méér in zit. Meer vragen om je leverancier te toetsen lees je in hoe je een softwarebedrijf kiest.
De kans in dit lek
Een lek als dit voelt als brandjes blussen. Maar het geeft ook helderheid. In één middag zag je welke systemen bijblijven en welke niet. En een systeem dat al jaren op een oude versie draait, doet meestal ook verder niet meer wat je bedrijf vandaag nodig heeft.
Daar zit de kans. Moet je toch upgraden, kijk dan verder dan het versienummer. Welke koppeling mis je al jaren? Welk handwerk doet je team nog omdat het systeem het niet kan? Stel je hetzelfde systeem voor, maar dan gekoppeld aan je boekhouding, met een portaal waar klanten zelf hun orders volgen, en met een team dat de uren die nu in overtypen gaan aan klanten besteedt.
Een upgrade is het moment om je software te laten doen wat je bedrijf nu nodig heeft, in plaats van wat het tien jaar geleden nodig had. Daar zijn drie routes voor. Je kunt je huidige systeem stap voor stap moderniseren, het op moderne techniek nabouwen of het volledig vervangen. Welke route bij jou past, lees je in ons artikel over legacy software vervangen.
Volgende stap
Wil je weten waar jouw software staat en wat het méér kan? In de potential check brengen we in één gesprek in kaart welke systemen bijblijven, welke niet en waar de grootste kans voor je bedrijf ligt. Je krijgt er een groeiplan op maat bij. Zo weet je bij het volgende lek precies wat er draait en wie er aan de knop zit.
