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 says it pulled thousands of working access keys for n8n out of public code on GitHub, and used them to walk straight into hundreds of live servers running the popular automation tool.
The research, first reported by The Hacker News, is not about a software flaw. It is about people 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, and so on). To make those connections work, n8n stores the passwords and API keys for every service it touches.
That makes an n8n server a very rich target. Break into one, and you often inherit the keys to a dozen other systems behind it.
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 a subset of 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 is 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 separate 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, which often exposes business logic and the names of connected systems. They can pull execution history, which frequently contains real customer data, invoice contents, or chat transcripts that flowed through the automation. They can trigger workflows on demand, sending emails or moving money if that is what the workflow does. And they can extract the stored credentials for downstream services (Slack, AWS, Google Workspace, internal databases), giving them a foothold well beyond n8n itself.
None of this requires a CVE, the industry's catalogue of software vulnerabilities. The tokens work because they are meant to.
How did the tokens end up on GitHub?
The usual way. Developers hard-code a token into a script for testing, forget to remove it, and push the code to a public repository. GitHub's search is thorough, and so are the bots that scrape it looking for secrets.
GitGuardian's own business is finding leaked credentials in public code, so this scan is very much 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, then check the execution log for runs you did not authorise. Restrict the n8n web interface to a VPN or a known IP range if it does not need to be on the open internet.
For ordinary users of services built on top of n8n, there is nothing to install or patch. The fix sits with the operators of the servers, not their customers.
