Acht keer in zes maanden
2026 is een roerig jaar voor cybersecurity. Binnen de afgelopen tien jaar moesten we een handvol keer alle zeilen bijzetten voor een kritieke kwetsbaarheid. In de laatste zes maanden al acht keer: Copy Fail, Dirty Frag, Fragnesia, ssh-keysign-pwn, PinTheft, Januscape, Bad Epoll, GhostLock. Er is iets ingrijpend veranderd.
Van 'vele ogen' naar 'vele LLM's'
De Wet van Linus - vernoemd naar Linux-maker Linus Torvalds - vat de belofte van open-source in één zin samen: "Vele ogen maken alle bugs ondiep." Genoeg mensen kijken naar de code, dus fouten worden vroeg gevonden. Dat werkte, zolang die ogen menselijk waren.
Fabien Potencier, maker van het PHP-framework Symfony, vatte de nieuwe realiteit onlangs goed samen: waar Symfony jarenlang ongeveer één security-melding per kwartaal kreeg, staat de teller nu op ten minste één per dág. Zijn verklaring: kwetsbaarheden in code vinden was jarenlang duur, tijdrovend en voer voor specialisten.
Dat is voorbij. Iedereen kan een AI-agent op een codebase loslaten, en die vindt altijd wel wat. Soms triviaal, soms ernstig. Heel ernstig. Het gros van de kwetsbaarheden die het nieuws haalden, zijn 'local privilege escalations', waarmee een buitenstaander - onder specifieke omstandigheden - beheerrechten over een server kan verkrijgen.
Er is nog iets veranderd. Waar een kwetsbaarheid vroeger op zichzelf stond, neemt hij nu meestal vriendjes mee. Zodra een onderzoeker een kwestbaarheid vindt en een donkerbruin vermoeden heeft dat er in dezelfde hoek van de code meer te vinden valt, kan die er een AI-agent op loslaten. Wat vroeger maandenlang graven was, kan een LLM vaak binnen tien minuten vinden. De ene kernelkwetsbaarheid leidt letterlijk naar de andere.
De embargo is dood
Vroeger ging het zo. Iemand vindt een kritieke kwetsbaarheid. Die wordt via veilige kanalen met een klein groepje vertrouwde mensen gedeeld. In alle stilte gaat men haastig aan de slag. Er wordt een einddatum afgesproken waarop de bug bekend wordt gemaakt. Tegen die tijd is er een fix beschikbaar, zodat iedereen systemen direct veilig kan stellen.
Dit noemen we de embargo-periode. Die is dood.
Neem Dirty Frag, een van de grote kernelkwetsbaarheden van mei. Onderzoeker Hyunwoo Kim meldde de bug netjes aan het Linux-kernel-team. Zonder te refereren aan het veiligheidsprobleem, werd een fix gepubliceerd. Een buitenstaander merkte die fix op, en maakte met behulp van AI een scriptje waardoor de hele wereld de kwetsbaarheid direct kon gaan misbruiken. Vergelijk het met een virus dat wild om zich heen slaat, zonder beschikbaar vaccin.
Potencier concludeert: "The quiet window is gone for good." Zodra een kwetsbaarheid ook maar ergens bekend is, kun je ervan uitgaan dat die op straat ligt. Wachten tot maandagochtend is geen optie meer.
Kortom: AI helpt niet alleen om sneller en eenvoudiger nieuwe kwetsbaarheden te vinden, maar ook om er direct werkende exploits voor te bouwen. Wat vroeger weken of maanden op de plank lag voordat iemand het in de praktijk kon misbruiken, is nu binnen uren operationeel.
"Ik heb eigen servers. Wat betekent dit voor mij?"
Er worden veel kwetsbaarheden gevonden, en het worden er veel meer. Veel meer. Je moet er snel op reageren. Heel snel. Dat is de eerlijke boodschap.
Twee dingen moeten in ieder geval op orde zijn:
- Inzicht in je inventaris. Welke sites & applicaties draai je, met welke versies, op welke servers, voor welke klant? Als je dat niet binnen een paar minuten kunt beantwoorden, ben je gegarandeerd te laat als er nood aan de man is.
- Inzicht in meldingen. Via welke kanalen hoor je het wanneer er een kritiek lek is? En hoe snel?
Hoe een échte managed hoster dit aanpakt
Onze klanten zijn bureaus, SaaS-bedrijven, webshops en platforms. Vaak met legio persoonsgegevens. Wat gebeurt er eigenlijk tussen "er komt een melding binnen" en "elke klant is gepatcht"?
Meerdere bronnen, jaarlijkse review
We houden via meerdere kanalen bij welke kwetsbaarheden er verschijnen. Eén van de betere bronnen is het Digital Trust Center van het Ministerie van Economische Zaken en Klimaatbeleid.
Als onderdeel van onze ISO 27001-certificering evalueren we jaarlijks welke bronnen we volgen, hoe ze binnenkomen, en hoe snel. Blinde vlekken kunnen écht duur uitpakken.
Altijd twee engineers op de triage
Elke melding wordt door minstens twee engineers beoordeeld. Gebruiken wij deze software? Onze klanten misschien? Wat is de reële impact? Dat één persoon een kwetsbaarheid verkeerd inschat - te licht, of juist te zwaar - is menselijk. Met twee mensen is die kans nihil.
We weten binnen minuten wie geraakt is
Zodra we weten dat een melding relevant is, moeten we weten waar het speelt. Bij welke klanten? Op welke servers? Voor welke versies?
Dat lukt alleen als je goed weet wat waar draait. Daarom installeren we zo veel mogelijk software als Debian-package, en niet door bijvoorbeeld lokaal te compilen (zoals traditionele controlpanels zoals DirectAdmin). De reden is inzicht: via onze monitoring-tool LibreNMS zien we precies welke Debian-packages voor welke klanten op welke server draaien.
Van playbook naar productie
Zodra de scope duidelijk is, maken we meestal een Ansible-playbook dat het probleem verhelpt: bijvoorbeeld een sysctl aanpassen, een package updaten, of een configuratie hardenen.
Die playbook belandt eerst in een merge-request. Die wordt gereviewd door een collega, ook als het snel moet.
Voor de uitrol gebruiken we Ansible. Voor de mede-nerds: we gebruiken een eigen 'inventory plugin' die alle Core-nodes automatisch ophaalt via de Core API (die klanten ook kunnen gebruiken). Zodra een nieuwe node wordt aangemaakt, verschijnt hij vanzelf in de inventory. Altijd compleet dus.
Tip: kernel patchen zonder reboot
Niet iedere kernel-kwetsbaarheid kent een workaround. De kernel moet dan worden geüpdatet, waarna een reboot nodig is om de nieuwe kernel-versie te effectueren.
Als alternatief biedt Core ondersteuning voor KernelCare: kernel-security-issues worden live gepatcht, terwijl de kernel draait. Geen reboot nodig dus. KernelCare is een commercieel product van TuxCare, en daarom een optie voor Core-nodes, niet de standaard.
Snel patchen is niet het hele verhaal
Snel patchen is noodzakelijk, maar eigenlijk niet voldoende. Het kan voorkomen dat een kwetsbaarheid al 'out in the open' is, terwijl er nog geen fix beschikbaar is.
Daarom stapelen we lagen, ook wel bekend als 'defense in depth': we vertrouwen niet op één veiligheidslaag. ASLR staat aan waar dat kan. En omdat de mei-kernel-bugs stuk voor stuk local-privilege-escalations waren - waarbij iedere legitieme lokale gebruiker op een gedeeld systeem een potentiële aanvaller wordt - hebben we een eigen namespacing-implementatie ontwikkeld die klant-omgevingen strak van elkaar scheidt. Lekt er iets bij één klant, dan hoeft dat niet automatisch een probleem te zijn voor de rest. Meer daarover op onze security-pagina.
Case: Copy Fail, zeven uur van test tot volledig beveiligd
Copy Fail, een van de ernstigere kernel-kwetsbaarheden van mei 2026, liet zien hoe dit in de praktijk werkt bij ons.
- 15:00 - we begonnen te testen op interne staging-nodes.
- 17:39 - alle klanten waren geïnformeerd. Klanten die extra aandacht nodig hadden, werden apart gebeld.
- 18:00 - de patch, uitvoerig getest, werd automatisch uitgerold via de Ansible-playbook.
- 22:00 - álle servers van álle klanten waren gepatcht.
Zeven uur, van test tot volledig beveiligd.
De frontlinie: onderschat de (mentale) druk niet
Onderschat niet wat deze eindeloze stroom doet met de mensen aan de frontlinie: developers, engineers, security-teams. Er is nooit echt rust meer, want op ieder moment kan er iets voorvallen waardoor er een streep door de weekendplannen gaat. Eigenlijk was dat altijd al zo, maar de kans, de urgentie en de veelheid zijn serieus toegenomen.
Bij iedere nieuwe kwetsbaarheid worden memes gedeeld als "I'm tired, boss". Dat lijkt een grap, maar is het niet.
Een oproep dus aan bureau-eigenaren, projectmanagers en iedereen die met een technisch team werkt: wees je bewust van de mentale druk die de nieuwe situatie oplevert. Vanuit betrokkenheid, en - laten we eerlijk zijn - ook uit eigenbelang. Niemand is gebaat bij DevOps-engineers en developers die met een burn-out thuiszitten.
← Terug naar Insights