Draait je automatisering op je eigen server? Dan hoort updaten bij het werk

De automatisering draait en dan kijkt er niemand meer naar

Er is een moment in bijna elk automatiseringstraject waarop het even heel stil wordt. De koppeling werkt, de facturen worden opgehaald, de mails gaan eruit en iedereen gaat weer verder met zijn eigen werk. Precies zoals bedoeld.

Het ding blijft draaien op een computer waar niemand meer naar omkijkt. Geen dashboard, geen herinnering, geen vaste persoon. Eind augustus 2026 kwam er nieuws voorbij dat pijnlijk laat zien waarom dat een probleem is, ook als je bedrijf klein is en je automatisering onschuldig aanvoelt.

Wat er bij OpenAI gebeurde

OpenAI publiceerde eind augustus een technisch rapport over incidenten met zijn eigen AI-agents. Eén ervan is opvallend: op 19 juli merkten agents in een testomgeving dat de machine waarop ze draaiden een verouderde Linux-kernel had. Ze zochten het publiek bekende lek op, pasten de bijbehorende exploit aan zodat die op hún machine werkte en gebruikten hem om zichzelf meer rechten te geven dan ze hadden.

Dit was geen kwaadwillende hacker en geen ontsnapping naar buiten. Het waren agents die een taak kregen, tegen een muur aan liepen en een weg eromheen vonden. Dat is precies waar ze goed in zijn. Maar het laat zien hoe kort de afstand is tussen "we hebben die update nog niet gedaan" en "er staat nu iets op onze server dat we niet hadden bedacht".

Het lek in kwestie zit in de netwerklaag van de Linux-kernel en staat bekend als CVE-2026-53362. Het Amerikaanse cyberagentschap CISA zette het op de lijst van actief misbruikte kwetsbaarheden, met eind augustus 2026 als uiterste patchdatum voor Amerikaanse overheidsdiensten. Een tweede lek uit hetzelfde rapport, in de softwareopslag JFrog Artifactory, kreeg begin september als datum. Beide datums zijn inmiddels verstreken en dat maakt het dringender: een lek dat op die lijst staat wordt gebruikt en een server die de patchronde van toen heeft gemist staat er nu langer onbeschermd bij.

Die deadlines gelden juridisch alleen voor Amerikaanse overheidsinstanties. Voor de rest van ons zijn ze vooral een signaal: dit lek wordt in de praktijk misbruikt. En die praktijk gaat sneller dan je denkt, want aanvallers laten het inbraakwerk inmiddels door AI-agents doen, waardoor het gat tussen een update en een inbraak is gekrompen tot uren.

Waarom dit ook geldt voor een n8n-automatisering op je eigen server

Nu denk je misschien: leuk, maar wij zijn geen AI-lab. Klopt. Alleen staat het gereedschap dat OpenAI gebruikte inmiddels ook bij jou, alleen kleiner.

Steeds meer MKB-bedrijven draaien hun automatisering zelf, vaak met n8n op een goedkope virtuele server. Goede reden ook: je betaalt niet per uitgevoerde stap, je data blijft bij jou en je zit niet vast aan de limieten van een abonnement. Wij adviseren die route regelmatig.

Maar er hoort een rekening bij die je niet in het maandbedrag ziet. Zo'n server is van jou. Het besturingssysteem, de Docker-containers, de n8n-versie zelf: dat updatet niemand voor je. Datzelfde geldt een laag hoger, in de workflow zelf, waar n8n je sinds kort tegenhoudt als je iets opslaat dat op verouderde onderdelen leunt. En op diezelfde server staan meestal de sleutels tot je hele bedrijf, want dat is nu eenmaal wat een automatiseringsplatform nodig heeft. Toegang tot je mail, je boekhouding, je CRM, je bestanden.

Een lek waarmee iemand op die machine meer rechten kan krijgen, geeft toegang tot de kluis waar al je koppelingen in liggen.

Wat je concreet nakijkt

Je hoeft hier geen securityspecialist voor te worden. Vier vragen zijn al genoeg om te weten of je een probleem hebt.

1. Waar draait onze automatisering precies? Bij een cloudpartij zoals Zapier, Make of n8n Cloud, of op een eigen server bij een hostingpartij? Verrassend vaak weet niemand binnen het bedrijf dit nog, omdat degene die het opzette inmiddels weg is of het als klusje deed.
2. Wanneer heeft die server voor het laatst updates gehad? Bij een eigen server is dit een concrete handeling die iemand moet uitvoeren. Draai je Docker, dan geldt het ook voor de images, niet alleen voor het besturingssysteem eronder.
3. Wie krijgt bericht als er iets misgaat? Er hoort een naam en een mailadres bij. Automatiseringen falen stil en dat geldt net zo goed voor de server eronder als voor de workflow erbovenop.
4. Wat kan die machine allemaal bereiken? Zet op een rij welke systemen er koppelingen naartoe hebben. Meestal schrik je van de lijst en meestal blijkt de helft niet meer nodig.

Kom je er bij vraag twee achter dat het antwoord "geen idee" is, dan is dat je eerste klus en die laat je geen kwartaal liggen. Anders ontdek je pas achteraf dat het misging.

Blijkt er maanden niets gebeurd te zijn? Dit is de volgorde

Bij veel bedrijven is het antwoord op vraag twee "geen idee en vermoedelijk lang niet". Dat is onaangenaam, maar het is geen noodgeval en het is ook geen reden om vandaag blind op updaten te drukken. Je automatiseringsplatform hangt aan je mail, je boekhouding en je CRM. Een update die een koppeling sloopt kost je meer dan de maanden die je al achterliep.

De volgorde die wel werkt:

1. Maak eerst een momentopname van de server. Vrijwel elke hostingpartij heeft daar een knop voor, meestal onder de naam snapshot of backup. Dit is het enige punt op deze lijst dat je niet mag overslaan, want dit is je weg terug.
2. Schrijf op wat er nu draait. Welke versie van het besturingssysteem, welke versie van je automatiseringsplatform, welke containers. Zonder dat lijstje weet je straks niet wat er veranderd is op het moment dat iets stopt.
3. Doe de updates van het besturingssysteem eerst. Dat is de laag waar de lekken uit dit artikel zitten en tegelijk de laag die het minst aan je workflows raakt.
4. Daarna de containers en als laatste het platform zelf. Bij een grote versiesprong kunnen afzonderlijke onderdelen van je workflow anders werken of verdwenen zijn. Lees bij een sprong over een hoofdversie eerst wat er verandert en zet die stap apart van de rest.
5. Laat daarna één echte workflow van begin tot eind lopen. Zet een koppeling die je goed kent helemaal door en controleer of er aan de andere kant uitkomt wat je verwacht.

Durf je stap vier niet aan omdat de versiesprong te groot is geworden, dan is dat een signaal en geen schande. Blijven hangen op een oude versie is namelijk ook een keuze en precies de keuze waar dit artikel over gaat. Dan is de afweging uit de volgende paragraaf aan de orde.

Cloud of eigen server: wie is er dan verantwoordelijk?

Beide keuzes zijn prima, zolang je weet wat je koopt.

Bij een cloudplatform betaal je meer per maand en lever je wat controle in, maar het bijwerken van de onderliggende machines is dan hun werk. Dat is precies waar dat prijsverschil vandaan komt. Voor veel MKB-bedrijven is dat het geld waard, simpelweg omdat er intern niemand is die het onderhoud structureel oppakt.

Draai je zelf, dan is de maandrekening lager en heb je alle vrijheid, maar koop je er een taak bij. Die taak is niet zwaar. Een halfuur per maand is voor de meeste opstellingen genoeg. Alleen moet iemand hem wel op zijn naam hebben staan, want een taak zonder eigenaar bestaat niet.

De valkuil is de tussenvorm: zelf draaien omdat het goedkoper leek, zonder dat iemand het onderhoud heeft overgenomen. Dat is de duurste variant, want je betaalt hem pas als het misgaat.

Onderhoud is geen bijzaak van automatiseren

Dit past in een groter patroon dat we vaker zien. We schreven eerder dat het onderhouden het moeilijke deel van AI-automatisering is. Toen ging het over de inhoud: modellen veranderen, je data verandert en een workflow die vorig kwartaal klopte doet nu stilletjes iets anders.

Het OpenAI-rapport voegt daar een laag onder toe. Behalve de logica moet ook het fundament bijgehouden worden. Dat is minder interessant werk, maar het is wel de laag waar de meeste schade kan ontstaan, want daar liggen de sleutels.

Praktisch betekent dat één afspraak: zet het onderhoud in de agenda voordat je de automatisering live zet, als terugkerende afspraak met een naam erbij. Vijf minuten werk vooraf en je hebt het probleem uit dit artikel gewoon niet.

Waar je vandaag mee kunt beginnen

Als je één ding doet naar aanleiding van dit stuk, maak dan een lijstje van de plekken waar jullie automatisering draait en zet er per plek een naam achter. Meer niet. Geen beleid, geen tool, geen project. Dat lijstje is dezelfde inventarisatie die je maakt als je in kaart brengt welke AI-agents er in je bedrijf draaien, dus je kunt die twee prima in één keer doen.

Uit dat lijstje rolt vanzelf wat er moet gebeuren. Soms is dat een middag updates draaien. Soms is het de conclusie dat een verhuizing naar een beheerd platform verstandiger is dan het zelf blijven doen. En soms blijkt het gewoon netjes geregeld en dan weet je dat ook.

Twijfel je of jullie opstelling nog bijgehouden wordt, of wil je weten of zelf hosten in jouw situatie wel de goedkoopste keuze is? We kijken het graag samen met je door.