Het Metabase-datalek van n8n in augustus 2026 raakte 136 gebruikersrecords, vijf daarvan met wachtwoordhashes — vijf maanden na een apart, inmiddels gedicht maar ernstig sandbox-escape-keten (CVSS 9,5 en 9,4) die al liet zien dat het platform elke opgeslagen credential kon lekken. Geen van beide incidenten maakt n8n uniek onveilig. Beide bewijzen hetzelfde architectuurpunt: een automatiseringsplatform is een kluis vol inloggegevens, en elk Nederlands mkb dat Exact Online, AFAS of e-Boekhouden via n8n laat lopen, moet het ook zo behandelen.
Wat gebeurde er met n8n en Metabase in augustus 2026?
Op 6 augustus 2026 liet n8n weten op de hoogte te zijn gebracht van een beveiligingsincident bij Metabase, een analysetool van derden die het bedrijf intern gebruikt. De ongeautoriseerde activiteit vond plaats op 3 augustus; Metabase, dat een kritiek zero-day SQL-injectielek had (bijgehouden als GHSA-vwf4-m7j8-wcjf, CVSS-score 10,0, in een niet-geauthenticeerd wachtwoord-reset-endpoint), verhielp het lek kort daarna.
Uit het onderzoek van n8n bleek dat 136 records met namen en e-mailadressen zijn geraadpleegd, verspreid over zowel self-hosted als n8n Cloud-gebruikers. Vijf van die records bevatten bcrypt-gehashte wachtwoorden van n8n Cloud-accounts; wachtwoorden van self-hosted installaties worden nooit met n8n gedeeld, dus die installaties waren door dit specifieke incident niet direct blootgesteld. Omdat de query's van de aanvaller, in de woorden van n8n, "een variabele, niet-deterministische set rijen" teruggaven bij elke uitvoering, kan het bedrijf niet exact vaststellen welke records zijn geraadpleegd — vandaar dat het credentials breed reset in plaats van alleen bij bevestigde gevallen. Het onderzoek bracht ook een oudere, losstaande bug aan het licht (al eerder opgelost via een pull request) die een klein aantal Cloud-wachtwoorden in platte tekst had opgeslagen; n8n benaderde die 25 accounthouders uit voorzorg rechtstreeks. Het bedrijf informeerde zijn Functionaris Gegevensbescherming en de Berlin Commissioner for Data Protection and Freedom of Information — het gebruikelijke meldpad voor een in Duitsland gevestigde verwerker onder de AVG.
Waarom is een automatiseringsplatform van nature een "credential vault"?
Het Metabase-lek raakte accountmetadata, geen workflow-credentials. Het structureel ernstigere verhaal speelt vijf maanden eerder. n8n werd begin februari 2026 op de hoogte gebracht van het lek en bracht binnen enkele weken een fix uit; onderzoekers van Pillar Security publiceerden vervolgens in maart de volledige technische onthulling van twee kritieke n8n-kwetsbaarheden die, aan elkaar geschakeld, een niet-geauthenticeerde aanvaller een n8n-instantie lieten overnemen en elke opgeslagen credential lieten uitlezen. Volgens Pillars analyse was het eerste lek — CVE-2026-27493, CVSS 9,5 — een second-order expression-injectiebug in de Form-nodes van n8n: omdat n8n een ingediende formulierwaarde in twee aparte passes evalueerde, kon een aanvaller een shellcommando in het Naam-veld van een openbaar formulier zetten en dat bij de tweede pass laten uitvoeren. Geschakeld aan een tweede lek, CVE-2026-27577 (CVSS 9,4), kon de aanvaller de sandbox van n8n volledig ontvluchten en commando's uitvoeren op de onderliggende server.
De formulering van Pillar zelf is de zin om te onthouden: "n8n is functioneel een kluis vol inloggegevens. Het bewaart de sleutels tot elk systeem waarmee het verbonden is. Eén sandbox-escape stelt de n8n-instantie én elk verbonden systeem bloot." Dat is geen kritiek die specifiek voor n8n geldt — hetzelfde geldt voor Make, Zapier, Power Automate of elke andere orkestratielaag die tussen uw bedrijfssystemen zit en de sleutels bewaart om ze te bereiken. Wat deze specifieke keten kwetsbaarder maakte, is hoe direct bereikbaar het aanvalsoppervlak was: Form-endpoints zijn bedoeld om vanaf het open internet bereikbaar te zijn, dus misbruik vereiste niets meer dan één openbare formulierinzending en één vervolgverzoek. Op de gedeelde, multi-tenant infrastructuur van n8n Cloud reikte de impact volgens Pillar nog verder — een sandbox-escape via de workflow van één klant kon een pad openen naar gedeelde infrastructuur die ook andere klanten bedient.
Wat veranderde de sandbox-escape-patch precies, en wat niet?
n8n bracht de fix uit in de versies 2.10.1, 2.9.3 en 1.123.22, eind februari 2026. Technisch verwijderde de patch de overbodige tweede expression-evaluatiepass die de injectie mogelijk maakte, voegde die meerdere globale identifiers toe aan de blokkeerlijst van de sandbox, en verstevigde de AST-bewuste identifier-analyse die bepaalt waar een workflow-expressie naar mag verwijzen. Elke instantie die nog op een oudere versie draait, heeft de volledige RCE-naar-sandbox-escape-keten vandaag nog open staan, bereikbaar via niets meer dan een openbaar formulier.
Wat de patch niet kon oplossen, omdat het nooit een codefout was, is het punt dat Pillars analyse expliciet benoemt: de credential-opslag van n8n is alleen zo veilig als alles eromheen. Het Metabase-incident in augustus is het bewijs. Het had niets te maken met de Form-node-bug, liep via een volledig losstaande interne analyseleverancier, en eindigde toch met n8n dat uit voorzorg gebruikerscredentials reset. Een gepatchte instantie en een verstevigde sandbox sluiten de specifieke kwetsbaarheidsklasse die Pillar vond. Ze doen niets aan uw eigen accounthygiëne, uw ritme van credential-rotatie, of de beveiligingsstatus van welke leverancier n8n zelf op zijn beurt weer van afhankelijk is.
n8n Cloud of self-hosted: welk risicoprofiel past bij een klein bedrijf?
Voor een bedrijf dat n8n draait zonder eigen beveiligingsfunctie — de meeste Nederlandse mkb's tussen de één en vijftig fte — is n8n Cloud meestal nog steeds de pragmatische keuze, juist omdat patchen daarmee de taak van n8n wordt in plaats van de uwe: zowel de sandbox-fix in februari als de credential-reset in augustus werden uitgerold zonder dat de meeste klanten iets hoefden te doen. De afweging die Pillar signaleerde is reëel — een sandbox-escape op gedeelde Cloud-infrastructuur brengt cross-tenant-risico met zich mee dat een single-tenant, self-hosted instantie niet kent — maar dat risico schuilt achter het eigen patchritme van n8n, dat tot nu toe sneller ging dan de interne IT-capaciteit van de meeste mkb's zou toelaten.
Self-hosten legt die verantwoordelijkheid bij u neer. Dat is de juiste keuze zodra iemand daadwerkelijk de beveiligingsadviezen van n8n volgt en de instantie behandelt zoals u een database met de API-sleutels van uw CRM zou behandelen: netwerksegmentatie, niet bereikbaar vanaf het open internet tenzij een workflow echt een openbaar endpoint nodig heeft, en gepatcht volgens een schema in plaats van wanneer iemand eraan denkt. Een bedrijf in de 250–500 fte-range dat al een eigen IT-beveiligings- of governancefunctie heeft, is de logischere plek voor self-hosted n8n; zonder die functie voegt self-hosten vooral een ongepatcht aanvalsoppervlak toe waar niemand actief naar kijkt.
Wat moet u deze week concreet doen als u n8n gebruikt?
Beide incidenten wijzen naar hetzelfde korte lijstje acties, ongeacht welk incident u het meeste zorgen baart.
- Controleer of uw n8n-versie 2.10.1, 2.9.3 of 1.123.22 of nieuwer is — alles ouder staat nog open voor de Form-node-keten van RCE naar sandbox-escape.
- Als u self-hosted draait, controleer elke workflow met een openbare Form-trigger op velden die in een expressie terechtkomen, en behandel elk veld op een openbaar formulier standaard als input van een aanvaller.
- Roteer de API-sleutels en OAuth-tokens van elk systeem dat n8n aanraakt met financiële of klantgegevens — Exact Online, AFAS, e-Boekhouden, WhatsApp Business — volgens een vast ritme, niet pas nadat een incident het nieuws haalt.
- Beperk elke gekoppelde credential tot het minimaal noodzakelijke: een workflow die alleen Exact Online-rapportages uitleest, heeft geen sleutel nodig die ook facturen kan aanmaken.
- Zet op n8n Cloud MFA aan en reset uw wachtwoord, ook als u geen directe e-mail heeft ontvangen — n8n zegt zelf niet zeker te kunnen vaststellen welke accounts door de Metabase-query's zijn geraakt.
Betekent dit dat u beter kunt overstappen naar Make of Zapier?
Nee — en de eerlijke reden is dat Make en Zapier dezelfde kluis vol inloggegevens zijn, achter een andere interface. Geen van beide heeft een eigen versie van Pillars onthulling gepubliceerd, maar dat zegt iets over waar beveiligingsonderzoekers hebben gekeken, niet over een fundamenteel andere architectuur. Onze vergelijking van n8n, Make en Zapier blijft overeind op features en prijs; dit incident verandert daar niets aan.
Wat het wel zou moeten veranderen, is de vraag die u stelt voordat u een live financieel systeem aan een automatiseringsplatform koppelt, of u dat nu zelf beheert of via een implementatiepartner laat doen: wat is het patchritme, hoe strak zijn credentials per workflow afgebakend, en is elke gekoppelde credential achteraf te controleren. Die derde vraag is ook waar het rechtenmodel van MCP de vergelijking waard is — dat nieuwere protocol is vanaf het begin ontworpen rond het afbakenen van wat een gekoppelde credential mag doen, en dat is een reden waarom het steeds vaker náást n8n opduikt in productieomgevingen, niet in plaats ervan. En als uw automatisering al klant- of financiële gegevens raakt en niemand in uw team op dit moment kan zeggen wat elke gekoppelde credential precies mag, is dat gat de moeite waard om te dichten voordat u de volgende koppeling toevoegt.
