Leaked n8n Tokens Left 321 Live Automation Servers Open to Anyone With a GitHub Search
GitGuardian found thousands of API keys for the popular workflow tool spilled into public code repositories, handing attackers a straight path to connected apps and stored secrets.
Key points
- GitGuardian researchers found 4,576 unique n8n API tokens spilled into public GitHub commits, tied to 1,255 different servers.
- Of those, 321 live n8n instances still accepted the leaked tokens at the time of testing.
- The team showed four ways attackers could use a valid token to steal data and reach connected apps, without exploiting any software bug.
- No patch fixes this: the tokens are working as designed, they were simply published by accident.
- Owners should rotate any n8n API token that has ever touched a public repository and audit workflow run history for unfamiliar activity.
Security firm GitGuardian pulled thousands of working access keys for n8n out of public code on GitHub, then walked straight into hundreds of live servers running the popular automation tool.
This isn't about a software flaw. It's about developers pasting secrets into code they then push to the internet.
What is n8n and why does this matter?
N8n is a workflow automation platform, meaning a tool that companies use to wire together their other software: a sales system talking to a spreadsheet, a chatbot talking to a customer database. To make those connections work, n8n stores the passwords and API keys for every service it touches.
That makes an n8n server a rich target. Break into one and you often inherit the keys to a dozen other systems behind it. We've reported on n8n twice in recent months: a sandbox escape patched in July and a login bug that let a valid token from one provider authenticate as a different user. This finding adds a third exposure vector, and unlike those two, it has no patch.
How big is the leak?
GitGuardian scanned public commits on GitHub and found 4,576 unique n8n API tokens linked to 1,255 hostnames. When its researchers tested those servers, 321 instances still accepted the leaked tokens as valid credentials.
An API token is essentially a long password that software uses instead of a human login. If it leaks, whoever holds it can act as the owner until it's revoked.
| Finding | Number |
|---|---|
| Unique n8n tokens found in public GitHub commits | 4,576 |
| Distinct n8n servers referenced | 1,255 |
| Live servers that accepted the leaked tokens | 321 |
| Attack techniques demonstrated | 4 |
What can an attacker actually do with a token?
Quite a lot. GitGuardian demonstrated four abuse paths, all achievable with nothing more than a valid token and a web request.
An attacker can list and read every workflow on the server, exposing business logic and the names of connected systems. They can pull execution history, which frequently contains real customer data or chat transcripts that flowed through the automation. Triggering workflows on demand is also possible, sending emails or moving funds if that's what the workflow does. Finally, they can extract stored credentials for downstream services such as Slack, AWS or Google Workspace, gaining a foothold well beyond n8n itself.
None of this requires a CVE, the industry's catalogue of software vulnerabilities. The tokens work because they're meant to.
How did the tokens end up on GitHub?
The usual story. Developers hard-code a token into a script for testing, forget to remove it, then push the code to a public repository. GitHub's search is thorough, and so are the bots scraping it for secrets. Our July story on CISA's own leaked AWS GovCloud keys showed the same pattern can hit even organisations whose entire job is security hygiene.
GitGuardian's business is finding leaked credentials in public code, so this scan is squarely in its wheelhouse. Worth flagging as a caveat, though the numbers are straightforward to verify against public GitHub data.
What should n8n operators do now?
Assume any token that has ever been near a public repository is burned. Rotate it in the n8n settings, check the execution log for runs you didn't authorise, and restrict the n8n web interface to a VPN or known IP range if it doesn't need to be on the open internet.
For ordinary users of services built on top of n8n, there's nothing to install or patch. The fix sits with the operators, not their customers. That's the frustrating part of a credential leak: the door was unlocked from the inside.
