GitHub commits zijn voor veel ontwikkelaars een archief van werkende configuraties, maar soms ook van gevoelige gegevens. Dat geldt opnieuw voor n8n API tokens: beveiligingsonderzoekers vonden tokens die publiek waren opgeslagen in commits en konden daarmee inloggen op n8n-instanties zonder een softwarefout te moeten misbruiken.
Het risico gaat verder dan “een token is gelekt”. Wie beschikt over een voldoende geprivilegieerde n8n-token kan workflowdefinities inzien, uitvoeringen ophalen en — afhankelijk van de instellingen — zelfs opgeslagen downstream-credentials laten gebruiken of de onderliggende waarden laten uitlekken. In dit artikel lees je wat er precies is gevonden en welke maatregelen je vandaag al kunt nemen.
Wat werd er ontdekt in GitHub?
De onderzoekers verzamelden n8n API tokens die vanaf april 2025 in openbare GitHub-commits stonden. Vervolgens koppelden ze elk token aan het bijbehorende n8n-hostname en deden ze een test met een read-only REST-verzoek om te bepalen of de token nog geaccepteerd werd door de betreffende instantie.
Uit de scan kwamen 4.576 unieke credentials naar voren die gekoppeld waren aan 1.255 hostnames. In totaal waren 896 instanties bereikbaar op het moment van testen, waarvan 321 instanties ten minste één gelekt token accepteerden.
Dat betekent dat gelekte tokens in de praktijk zorgden voor geauthenticeerde toegang tot ongeveer 36% van de bereikbare instanties die zijn getest. Voor de hostnames lag dit rond 26%.
Waarom n8n zo’n interessant doelwit is
n8n is een open-source (low-code) workflowautomatiseringsplatform met veel ingebouwde integraties. Organisaties gebruiken het om applicaties met elkaar te verbinden, bijvoorbeeld voor:
- databanken en interne systemen
- broncode repositories en CI/CD-achtige processen
- cloudomgevingen en API’s
- AI-diensten
- klantondersteuning en andere bedrijfsplatformen
Werkflows bestaan uit nodes die gegevens verwerken, code uitvoeren of extern verbinden met behulp van opgeslagen referenties zoals API keys, tokens en databasewachtwoorden.
Die tokens zijn weliswaar versleuteld “at rest” met een master secret (N8N_ENCRYPTION_KEY), maar n8n moet ze toch decrypten en gebruiken wanneer een workflow draait. Als een aanvaller inlogt met de juiste n8n API tokens, kan die aanvaller workflowacties laten uitvoeren onder het gezag van de gebruiker die de token heeft aangemaakt.
Hoe blijven tokens bruikbaar, ook als je ze ooit aanmaakte?
Een n8n API key is een signed JSON Web Token met onder meer een “aud” claim: public-api. Belangrijker dan alleen de structuur is of de sleutel nog bestaat en geldig is binnen de n8n-database.
Daarnaast speelt de aanwezigheid (of juist afwezigheid) van een vervaldatum een rol. In eerdere versies werd een standaard “30-daagse” expiratieterm geïntroduceerd. Tokens die zonder exp claim zijn gegenereerd, kunnen daardoor nog maanden later geaccepteerd worden, totdat iemand ze expliciet intrekt of verwijdert.
Wat kan een aanvaller doen met een geauthenticeerde n8n-token?
De impact hangt af van de permissies van de gebruiker achter de token. Veel tokens die in het onderzoek opdoken leken afkomstig van instance owners of beheerders, waardoor de mogelijke toegang relatief breed was.
De onderzoekers noemen expliciet dat de openbare REST API (binnen de rechten van de geauthenticeerde account) onder meer kan blootleggen:
- Gebruikersinformatie (afhankelijk van rol)
- Workflowdefinities inclusief nodeconfiguraties
- Credential metadata (naam/type/deling, maar niet per se de echte geheime waarden)
- Workflow-uitvoeringgeschiedenis
- Data uit datatables die voor die gebruiker zichtbaar zijn
- Variabelen en de inhoud daarvan (vaak alleen voor owners/admins)
Workflowdefinities zijn extra gevoelig omdat daarin complete nodeconfiguraties kunnen staan. Als ontwikkelaars een token of API key direct in een nodeparameter zetten (in plaats van via n8n’s credential store), kan het ineens in de interface zichtbaar worden — en via de REST-API ook.
Het credential-endpoint geeft niet altijd de onderliggende geheime waarde terug. Maar in combinatie met de juiste rechten kan een aanvaller wel workflows laten draaien die opgeslagen credentials gebruiken, of data laten “terugkomen” via uitvoerrecords.
Het audit-endpoint als routekaart voor aanvallers
n8n heeft een audit endpoint dat (met een geldige token) een security report kan opleveren. Voor een legitieme beheerder is dat handig voor review en hardening. Voor een aanvaller wordt het een soort prioriteitenlijst van mogelijke ingangen.
In de praktijk kan de audit output onder meer wijzen op:
- mogelijke SQL-injectiegevoeligheden in workflows
- nodes met filesystem-toegang
- onbeschermde webhooks
- de draaiende n8n-versie (om die te koppelen aan bekende issues)
- ongebruikte credentials
- hoog-risico of community-installed nodes
- ingeschakelde beveiligingsfeatures, allowlists en blocklists
- telemetry- en andere configuratie-informatie
Vier aanvalstechnieken zonder CVE-exploit
Een belangrijk detail: de onderzoekers demonstreerden de risico’s in een gecontroleerde n8n-omgeving, zonder CVE-exploit of gespecialiseerde tooling. Er waren alleen standaard HTTP-requests nodig, gebruikmakend van legitieme REST-functionaliteit van n8n.
Hun testworkflow bevatte drie doelbewuste zwaktes: een webform dat input opslaat in een data table, een OpenAI node die werkte met een opgeslagen credential, en een HTTP Request node die GitHub gebruikte met een token in de nodeparameters.
Techniek 1: de instantie “in kaart brengen”
Met een geauthenticeerde token konden ze zonder workflowaanpassingen enumereren. Zo leverde GET /api/v1/users een klein setje accounts op (owner, actieve gebruikers en een pending registratie).
Daarna bleek GET /api/v1/workflows voldoende om volledige workflowdefinities te krijgen. In het voorbeeld zat in één workflow een GitHub token in plaintext binnen een HTTP Request node.
Techniek 2: een opgeslagen OpenAI credential gebruiken
Via GET /api/v1/credentials konden ze credential objecten vinden (naam/type/id), zonder direct de geheime waarde te zien.
Vervolgens maakten ze een nieuwe workflow met een Schedule trigger en een OpenAI node die naar de credential by ID verwees. Omdat de schedule-trigger automatisch afvuurde en er later met GET /api/v1/executions?includeData=true volledige uitvoeringdata werd opgehaald, kon het resultaat van de OpenAI node in plaintext worden teruggezien. Het token zelf hoefden ze dus niet te stelen om toch de prompts te kunnen laten uitvoeren.
Techniek 3: een data table uitlezen via workflow-uitvoer
Ook hier werkte het patroon met een Schedule trigger en een Data Table node. Door daarna execution data met includeData=true op te halen, kregen ze de tabelrijen in plaintext terug in de execution record.
Dat leverde gevoelige gegevens op, zoals namen, e-mailadressen, formresponses en verwerkingsstatussen. Daarna verwijderden ze de workflow weer; afhankelijk van hoe de organisatie kijkt, kan dat bewijs binnen n8n beperken.
Techniek 4: de raw credential exfiltreren door “door te sturen”
De meest vergaande stap was het daadwerkelijk uitlekken van de onderliggende geheime waarde. De truc was dat een HTTP Request node een stored n8n credential kan gebruiken als authenticatiemethode, terwijl de request naar een aanvaller-controlled endpoint gaat.
Door een listener te starten en een workflow te activeren die de OpenAI credential als Bearer token gebruikte naar die listener, konden de onderzoekers de echte API key ontvangen zodra n8n de outgoing request deed.
Na afloop verwijderden ze de workflow weer om sporen binnen de interface te verkleinen.
Wat zegt dit over “echt bestaande” workflows?
De demonstratie was niet puur theoretisch. In de onderzoeksdata werden ook realistische patronen gezien die vergelijkbaar waren met de opzet uit het lab.
Een voorbeeld: een workflow die automatisch backupte naar een publieke GitHub repository, waarin een SSH deployment key direct in een node zat. De Git geschiedenis bevatte eerdere workflowversies, en de sleutel bleef daarbij geldig. Met andere woorden: de workflow publiceerde zichzelf en dus ook gevoelige configuratie en credentials bij elke run.
Waarom dit verder gaat dan alleen n8n
Het grote gevaar is dat n8n niet op zichzelf staat. Het platform zit als schakel tussen meerdere systemen. Als een aanvaller via n8n API tokens bij de juiste workflowcontext komt, kan die in één beweging:
- bron- en workflowdefinities inzien
- uitvoeringdata terughalen
- stored credentials laten gebruiken richting derde partijen
- mogelijk downstream account- en API-toegang vergroten
Daarmee definieert de “blast radius” zich niet alleen door de n8n-instantie, maar door alles wat eraan gekoppeld is: repositories, databases, cloud services, AI API’s en interne klantdata.
Wat kun je doen: praktische maatregelen
Als je n8n gebruikt, is het verstandig om dit risico te behandelen als credential exposure met potentiële kettingeffecten. De volgende stappen helpen om de kans op misbruik te verlagen en om impact te beperken.
1) Intrek en roteer direct gelekte of verdachte tokens
Zie een gecompromitteerde n8n API token niet als “een klein incident”. Start met revocatie. Vervolgens roteer je aangesloten secrets die door workflows worden gebruikt.
2) Beoordeel welke rechten de token had
Check vooral: kon de token workflows lezen, data tables uitlezen, executies opvragen of nieuwe workflows laten draaien? Hoe hoger de permissies, hoe groter het risico op exfiltratie.
3) Zoek naar harde secrets in workflowparameters
Let op workflowdefinities waarin tokens direct in nodeparameters zijn gezet. In dat geval kan een aanvaller via read-only API’s alsnog de waarde zien of via execution output terugkrijgen.
4) Review audit- en beveiligingsinstellingen
Gebruik het auditrapport (legitiem) om te bepalen welke configuraties extra aandacht vragen: webhooks, allowlists/blocklists, nodes met hogere privileges en ongebruikte credentials.
5) Kijk ook naar externe representaties zoals backups
Als workflowdefinities automatisch naar GitHub worden teruggeschreven of geback-upt, kan “code review” of .gitignore bescherming onvoldoende zijn. Controleer of hostnames en tokens ooit samen in commits terugkomen.
Conclusie
De vondst van n8n API tokens in openbare GitHub commits laat zien dat credential theft niet altijd begint met het misbruiken van een kwetsbaarheid. Met een geldige, geprivilegieerde token kan een aanvaller n8n via reguliere REST-functionaliteit gebruiken om workflowdefinities, uitvoeringdata en gevoelige koppelingen naar andere systemen bloot te leggen.
Revocatie en rotatie zijn noodzakelijk, maar minstens zo belangrijk is een bredere beoordeling: welke workflows konden wat, waar staan harde secrets, en welke downstream systemen lopen risico door de integraties van n8n?
Door die keten vroeg te herkennen, verklein je de kans dat één gelekte token verandert in een grotere inbraak via automatisering.
Gerelateerd lezen: Gitea kwetsbaarheid: oningelogd bestanden uitlezen en ChainDrop: 400+ NPM pakketten besmet geven extra context over hoe exposure in ontwikkelketens en integraties kan doorwerken naar echte compromises.
Bron: https://thehackernews.com/2026/08/leaked-n8n-api-tokens-exposed-live.html
