Het PHP lek en wat we moeten leren over cybersecurity in 2026

Niemand zal het ontgaan zijn vorige week. Het halve internet lag plat. Ziekenhuizen en de Tweede Kamer haalden hun websites offline. Chaos, kamervragen en één naam die overal opdook: PHP2Shell. Een kwetsbaarheid in de programmeertaal achter 70% van het internet. Pas aan het einde van de dag was er een oplossing.

Wat minder aandacht kreeg: de volgende dag was er alweer een grote kwetsbaarheid. Dit keer in Brotli. En de dag daarna opnieuw. Afgelopen dinsdag waren Mac en iOS aan de beurt. Terwijl we dit schrijven, op 30 oktober, is het de Linux-kernel. Nog steeds zetten we delen van websites op zwart omdat er een kritiek beveiligingsprobleem is, maar nog geen officiële oplossing.

Precies daar wringt het. Er is iets fundamenteels veranderd. In hoe aanvallers kwetsbaarheden vinden en misbruiken. En in de mogelijkheden die beveiligers hebben om daar op tijd iets tegen te doen.

Binnen een uur aangevallen. Hoe zijn we hier beland?

Hoe gevaarlijk is een kwetsbaarheid? Dat beoordeel je per applicatie. Kan een aanvaller het kwetsbare onderdeel bereiken? Hoe groot is de kans op misbruik? En wat is de schade als dat lukt?

Vooral bij die laatste twee loopt het risico steeds verder op. Bij kwetsbaarheden zoals PHP2Shell kunnen aanvallers complete servers overnemen. Een website die aan het internet hangt, kan daarmee een ingang worden.

De impact is groot. En de snelheid waarmee aanvallers zo’n kwetsbaarheid kunnen misbruiken, neemt toe.

De waarschuwingen waren er al

Palo Alto Networks publiceerde in 2023 een rapport met een alarmerende conclusie: 80% van de onderzochte kwetsbaarheden werd al misbruikt voordat ze waren gepubliceerd. Gemiddeld 23 dagen eerder. Wachten op een officiële classificatie, destijds de gebruikelijke werkwijze, betekende dus dat je achter de feiten aanliep.

In 2025 volgde een nieuwe waarschuwing. Bruce Schneier, Heather Adkins en Gadi Evron beschreven hoe AI ongeveer 30% van de bekende kwetsbaarheden binnen een dag misbruikbaar kon maken. De consequentie: patches moeten binnen een dag worden geïnstalleerd. Hun waarschuwing was helder: binnenkort kunnen we dit tempo als beveiligingsgemeenschap niet meer bijbenen.

In 2026 zien we die ontwikkeling doorzetten. AI kan zelfstandig kwetsbaarheden ontdekken en misbruiken die al tien jaar in software zitten, zoals bij PHP2Shell. En een officiële update? Die helpt ook aanvallers op weg. Anthropic beschreef in juni 2026 hoe de inhoud van een patch als bouwtekening voor een aanval kan dienen. Vaak is daar binnen een uur werkende aanvalscode van gemaakt.

Ook een bekend probleem mét een beschikbare oplossing wordt dus gevaarlijker. Zeker als die oplossing nog op je actielijst staat.

Aanvallers hebben uren nodig. Verdedigers nemen dagen.

De tijd om een patch door te voeren, wordt steeds korter. Uren kunnen het verschil maken. Toch duurt het uitrollen van een kritieke Windows-patch in de praktijk mediaan 7,7 dagen, volgens Action1.

Dat verschil is precies het probleem.

PHP2Shell laat zien wat er gebeurt als aanvallers sneller zijn dan de verdediging. De kwetsbaarheid wordt gevonden en misbruikt terwijl er nog geen officiële oplossing is. Een website offline halen kan dan de enige overgebleven maatregel zijn.

Ondertussen lopen officiële kanalen achter en zoeken beveiligingscommunities naar tijdelijke oplossingen. Er wordt hard gewerkt. Maar zolang er geen werkende bescherming is, blijf je kwetsbaar.

En dan hebben we het nog niet over updates die helemaal niet worden geïnstalleerd. Over vergeten applicaties. Over software waarin niemand meer investeert. Over IT-budgetten die te klein zijn om het onderhoud bij te houden.

Wie 100% veiligheid belooft, belooft te veel. Ook de beste beveiligingspartij kan niet garanderen dat een onbekend lek wordt tegengehouden als daar nog geen maatregelen voor zijn.

De tijd van kleine investeringen en versnipperd onderhoud is voorbij

Cybersecurity vraagt om structurele aandacht. Om budget, duidelijke verantwoordelijkheden en de mogelijkheid om snel te handelen. Dat heeft concrete gevolgen voor hoe je applicaties bouwt en onderhoudt.

Maak onderhoud een vaste prioriteit. Breng applicaties bij met de laatste updates en houd ze bij. Dat mag niet steeds wijken voor nieuwe functionaliteit of een krap budget. Acht uur per maand is te weinig om een applicatie goed te onderhouden én de beveiliging voldoende aandacht te geven.

Maak beveiliging onderdeel van het dagelijkse werk. Bescherming tegen kwetsbaarheden vraagt om een proactieve aanpak, met vaste controles en ingepland onderhoud. Dat is een verantwoordelijkheid van iedereen die bij het product betrokken is. De DevOps-engineer kan dit niet alleen dragen.

Investeer in sneller updaten. Updaten, testen en publiceren kost vaak nog uren handwerk. Automatiseer waar dat kan. Hoe sneller je een update veilig kunt uitrollen, hoe korter je kwetsbaar bent.

Houd rekening met onderbrekingen. Noodupdates en tijdelijke onderbrekingen zullen vaker voorkomen. Zorg dat je team daarop is voorbereid en dat duidelijk is wie beslist en handelt.

Zorg minimaal voor een centrale beschermlaag. Een firewall die schadelijk verkeer snel kan blokkeren, is in 2026 een basisvoorziening. Partijen als Cloudflare en Azure hebben de schaal om snel beschermingsregels te ontwikkelen en breed toe te passen. Zo’n laag helpt actief misbruik te herkennen en tegen te houden, ook buiten kantooruren. Die snelheid kan een onderhoudspartij of eigen ICT-afdeling moeilijk alleen leveren. Deze bescherming achterwege laten, is onverantwoord.

Hulp nodig?

Hoe goed is jouw applicatie beschermd? Bij theFactor.e denken we graag met je mee. Samen brengen we de risico’s in kaart en bepalen we welke maatregelen nodig zijn. Van structureel onderhoud tot snel kunnen handelen als het misgaat.

Laten we in gesprek gaan.